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SECTION I 
INTRODUCTION 



OVERVIEW OF STUDY 

This report is the result of a study thati 

o Took a global look at Instructional Support Systems 
(ISS) / then 

o Created a functional ISS design for a specific flight 
training simulator (F14A) , and 

o Tailored the design to fit a realistic budget and 
schedule. 

The need for the study caine about by the requirement to 
minimize the use of advanced Fleet aircraft for training and 
the need to maintain and preferably improve the quality of 
aircrew training. In spite of the miniini^ed use of aircraft 
for training purposes^ the current high coat and limited 
availability of advanced Fleet aircraft for training has 
greatly increased the Navy's need to rely on training simulators 
to reduce training costs without sacrificing operational 
readiness. This then requires more use of flight simulators in 
such a manner that the flight training standards are achieved 
In a cost effective manner* These objectives can be realised 
by the continued application of the instructional system 
development approach and the enhancement of the instructional 
capabilities of present future training simulators. 

The technology of autortiated instructional support offers 
the potential for reducing the instructor's workload while 
providing a means for further improving the efficiency and 
quality of training with simulators. In particular/ the ISS 
can be expected to: 

o Standardize training 

o Measure performance objectively 

o Adapt the scheduling of the training tasks 

o Advance the student through the curriculum according 
to proficiency 

o Motivate the studeiit 

o Aid instructional Tnanagement 

This can be achieved by a system design which i 
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o Provides tha Instructor Pilots (IP) ^rith automatQd 
supports that can relieve thmm of ancillary inatruc- 
tional tasks, 

o Provides automated auKiliary support by incorporating 
support capabilities typically not found in training 
simulator settings, 

o Providas an Instructional Support System (ISS) that 
will facilitate ongoing refin:' xg and testing, 

THE AUTOMATED l^^STRUCTIONAL SUPPORT GYSTEM SETTING 

In any instructional satting, the instructor's primary 
duty is to teach^ i^e,^ to transmit knowledge and guide the 
student's learning. Flight aimulators offer the potential for 
very effectiva instruction because of the control that can be 
exercised over the training situation. However^ instructor 
tasks that are ancillary or secondary to teaching often reduce 
the efficient and effective use of flight sirnulators. It has 

been estimated that approximately 20 percent of the IP's time 
during aach simulator training aession must be devoted to ancilla 
tasks , Automated instructional support ean reduce this time by 
providing assistance in the parforrnance of such antillar tasks as 

o System initializiation 
o Probleni set up 
o Note taking 

o Acting as missing crewmember 
o Mission communications 

Automated instructional support technology also offers the 
potential for enhancing the quality and for standardization of 
simulator training by providing IP's and training management 
personnel with auxiliary capabilities not previously available* 
Auxiliary task support can include- 

o Computer-resident syllabus to facilitate planning and 
standardization 

o Computer^generated pre-^session briefing aids 

o Automated Replacement Pilot (RP) readiness testing 

o Automated performance measurement and scoring 

o Data files for objectively establishing quantitativQ 
performance norms 
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o Autojtiated preBcription of: subsequent training 

o Autoinated maintenance of atudGnt progrGSS files 

o Automated performance summaries for debriefing 

The general functional flow of an Autoxnated Instructional 
Support System that would accornplish the foregoing purposes is 
shown in Figure 1* 

Projects leading toward the developnient of effective 
instructional support systems have been sponsored by the Naval 
Training Equipment Center for some time* Early work established 
the JEeasibillty of automating a syllabus for aircraft v^eapon 
systeiTi training (Leonard, Doe and Hofer^ 1970; and Futas, 
Butler and Johnson^ 1972) , The concepts were demonstrated in 
the laboratory (Charles and Johnson^ 1971; Charles^ Johnaon 
and Swink, 1972 and 1973), and later implemented in the field 
at Luke Air Force Base (Swink etal., 1975), and for the Greek 
Air Force (Butler, Langford and Futas, 1975; and Butler, 
Barber and Futas, 1975), Parallel automated performance 
measurement work was performed for the Navy during the saine 
time frame (Vreuls and Obermayer, 1971; Vreuls, Obermayer and 
Goldstein, 1976; and Wooldridge, Breaux and Weinman, 1976). 

Successful demonstrations also have been made of the 
technical feasibility of computer automated problem set up, 
performance measurement and control of the next exercise for 
selected segments of Instrument flight training. Ground 
Controlled Approach (GCA) and TACAN approaches, Air-- to-Air 
Intercept (AAI) , and Grouhd Attack Radar (GAR)* Automation of 
probleni briefing, air and ground controller voice messages, 
problem dynamic replay, and limited instructional coaching also 
have been achieved* Computerized Speech Understandinq Systems 
(SUS) have been installed in the laboratory and at an opera- 
tional flying training establishment (Fuege and Grady, 1975) * 

These demonstrations show that it is possible to use 
existing hardware and software technology to automate various 
instructor functions* initial applications have been shown to 
offer training benefits (Puig and Gill, 1975; and Brown, Waag 
and jUddov/es/ 1975). 
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SU^iMARy 

Based on the current state of ISS technology this study 
achieved the following objectives s 

o Developed an ISS structure and concept that has general 
aircrew training application to any aircraft type yet 
is flexible enough to be progranmed to meet a specific 
Fleet requirement. 
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Figure 1. Flight Training Simulator MtOMtid Instructional 
Support Systf'!! Functional Plow 




o Developed a furiction design fox an automated ISS that 
could be "strapped onto" an existing F14A Operational 
Flight Trainer (OFT) (Device 2P95) which will enhaiice 
pilot training by more effective use of the IP, 

The follpwing definitiona amplify program objectiv^es and 
the type of ESS desigri that was pursued^ 

o Instguc tional support is providing compiiter aeaistance^ 
through autoniation/ for the performance of ancillary 
and auxiliary instructional tasks, 

o AnciLlary instructional tasKs ar© those r^outine 

activities that are required sinnply to lase training 
devices in present coiif iguration, 

o AuxiLlary taslc support i s providing instructors and 
trairiirig manageJ^ent with aide and inforniation that can 
be used to more objectively and comprehensively ensure 
traiiiing quality. 

o Stratification of feature autornation ti the struGturing# 
of supported instructional actlv^ities into functiorial 
classes so that the classes car> be ordered in a hierarchy 
representing a seal© of support wherein each step or 
level can subsume all levels below it. 

o An e)cperimental ISS is one that is capable of aQntrib-- 
ijting to automated InstruGtional research, and is 
flexible enough to be modified to benefit froiri it* 

o Ji flexible ISS is one that can be reprcgraimned to niodify 
Anstruetional support characteristiGs • riexibility also 
centers on proi^lding the Instructor aflacgaata means to 
tailor the natiare and amount of support to match 
individual instructional needs* 



The report of the study that follo'^^s is divided into six 
significant parts as follows^ 

o A discussion of the methodological approach taken to 
the problein which covers analysis of the IBS reqiiire^ 
nients , the development of a specific ISS concept that 
y/ill fulfill the needs uncovered by the prior anali^sls 
and a system design through v^hich the ISS concept can 
be implemented , 



o A description of the training environment which warn 
used as a baseline for the ISS requirenients analysis , 

o A dissertatiori on the determining features and 

operational character of an optiinum or -'fiall support-* 
JSS on \/hich the F14A and subsequent system designs 
can be predicated. 



o All operational descriptioii of the proposed si^steiri to 
show its cornpatibility with existing trainlrig 
simulators and tt^ining reguirements^ 

o An outLine of the hardw^are and software design v/hlch 
is the basis for subsequeiit system specifications , 

o An impLementation and atoinlstiation plan by which the 
ISS cmn be brought into operational use. 

Because of the v/ifle ranging disciplines invol^red in this 
stuay it has been difflcialt and at times impossible to qualify 
and record the rationale for the namerous deciaioiis that 
provided its direction . To say the leasts much good judgnient 
and experience prevailed^ each iaidividual involved realising 
that the resultant rss will require significant fle^clbility to 
acconmiodate tuaiiig, modification and validation of the basic 
design. 
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SECTION It 
APPROACH TO THE PBOBLEM 



ISSUES AMD ^CONSIDERATIONS 

The appxoach was intended to ensure that the ISS Cunctional 
design would be responsive to the needs of both operational 
training and research. Kay elements considered weres 

o Instructional support needs, as defined £rom an 
operational training referance point, would 
largely provide the guidance £or deterinlning the 
bandwidth for automated support capabilities to 
be incorporated in the ISS funational design. 

o The ISS design must capitalize an the strengths 
and compensate for the weaknesses of present 
instructional support system technologies, in- 
cluding instructional techniques, hardware and 
software. Therefore, the design must incorporate 
capabilities that enable it to be used in a 
research role as well aa sn instructional role 
to optimize the capitalization/coinpensatlon 
rationale. 

o Support capabilitiss incorporated into the ISS 

objectives should not be limited by a-priori judg- 
ments o£ iinplementation difficulties and constraints. 
Rather, a full support sy stein should be conceived 
and then any reasonable subset of capabilities 
could then be selected for implementation. 

o ISS hardware and softv^are designs should be based 
on state of the art technologies to ensure an 
efficient and compact system. Teahnology that is 
"advanced" state of the art could be used if 
developraental risks are modest. 

o The ISS design should complement, rather than 
duplicate, instructional features of the host 
simuLator's instructors console. 

o System capabilities, as expressed through the man- 
machine interface, itiust have user acceptance and 
require minimal inatractor training, 

Q The design must acknowledge that pilot training 
and the use of a particular flight simulator to 
accomplish the training are dynamic and changing. _ 
Therefore, certain instructional support capabilities 
must be modifiable with relative ease. 
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o The ISS design must be generaligable to simulator 

training appliGations other than those characterizing 
a particular instructional setting or cievice* 

o The resulttng system design*, when irnpleinented, must 
be transpat^nt to the host simulator, thus not inter- 
fering with or requiring modification, to tha simulator's 
software. 

METHOD ' 

Recognizing that designing such a system was highly innova-^ 
tive, research nedesaitated venturing beyond vfhat has been tried 
and proven* The methoSology used is sho'wn in simplified form in 
Figure 2. In the absence c£ implemeiitation arid operational 
feedback, the design process used was largely open loop snd based 
upon best estimates. As implied in Figure 2, feedback ultimately 
will be required to optimize features of the iystem, detennine 
their utility and acc^ptMce^ and establish gaidelines Cor 
generalizing the design faatares to other applications- 

The approach to the problem was divided into three phases ? 

Phase I, Analysis of KcqulrementB and technologiei5 
Phase II. pevelopment of a Spaciffic Coneept 
Phase III. Systan Design 

PHASE I -mMj^sis OF mouimm^m. Pigure 3 showy 

the Phase I tasks, Activities in the phase aantered upon d^ter-- 
mining operational instructional support requireinentia * Parallel 
activities eKamined instructional technolQgy that could be brought 
to bear on the problanir and hardware and software constraints 
that could affect ISS design. 

Fleet Readiness Squadron (PRS) VP-124, at NAS Mlramar, CA.r 
was used as the operational training enLvironment for establishing 
support requirements. Device 2F95 (F^L4A OFT) was established 
as the candidate host simulator for an ISS iitiplementation. 

Initial activities centered upon establishing present ^nd 
anticipated uses of the OPO' in the FRS syllabus. Of the two OTTb 
at Miramar/ the one selectea incorporated a ri1AL-2 visual system. 
This visual system uses point light soutces to display night 
visual imagery which is limited to a relatively narrow forward 
field of ^?iew* 

Both OFTs are single s©at simulators* P^n Instructor's 
console containing various repeater instruments and annunciators 
is located remotely from the cockpit. 
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Analysis of the OFT was done for Fleet Squadrons as well as 
VP-124. Fleet personnel typically use the OFT electronically 
linked 'to Device 15C9, the Mission Trainer, for integrated aircrew 
training and NATOPS checks. The lliikea mode enables training on 
tactical problems. This is not possible in a stand-alone OFT . 
Taken together, analysis of FRS anfl rleet usage provided informa- 
tion on a broad sample of weapon systsni training tasks to which 
ISS design may ultimately have to be responsive. 

Instructor interviews. Training Device Operator (TD) inter- 
views, and training exercise observations were completed to 
identify ancillary instructional functions and provide a focus 
for prescribing meaningful automated instructional support. 

This part of the analysis phase was Goncluded with a review 
of Instructor Under Training (lUT) syllabus materials and prac-_ 
tices. This was done to establish the type and amount oJ training 
that IPs tvplcally receive on the use of the OFT in the FES pro- 
gram. This provided a baseline £ox estimating special training 
requirements for the effective use of the ISS. 

One parallel activity examined on-going and recently com- 
pleted instructional support research to assess the potential 
utility of recent advances in: 

o Computer-resident syllabus structures 

o Automated performance measuE'eiTient and scoring 

o Instructional man-machine interfaces 

o Automated adaptive training 

The main purpose of the eKsminatlon was to evaluate the 
status of these technologies for field application. An adjunct 
purpose was to examine and, hopefully, benefit from lessons 
learnad in the laboratory and from the field as they relate to 
system utility and system design for user acceptance. 

A second parallel activity involved interviews with OFT 
maintenance personnel and a review of OFT hardware and software 
documentation. The primary objective was to establish the feasi- 
bility of a strap-on, transparent Interface. A second objective 
was to establish the adequacy of the technical documentation of 
the OFT for use in later design work. 

The culmination of Phase I was the integration of analysis 
information to establish goals and bounds for Phase II. 

PHASE II - DEVELOPriEMT OF A SPECIFIC CONCEPT. The goal _ 
of Phase II was to draw upon available information and experience, 
and develop an integrated ISS concept. The tasks involved in 
this iterative and largely inventive process are shown in Figure 4 
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o Refine candidate automted siipport capabilities 

into a set of easily understandable modes of operation, 

o Evolve an operational systein structure that organizes 
support capabilities hierarchically. 

Q Refine requirements of reeearoh as they relate to the 
anticipated needs of ISS development in the field* 

o Evaluate the requiremeats of research on hardware and 
software design, 

o Evaluate alternative rnan^machine interface designs 
in terms of system utility^/ user acceptance, and 
lUT training. 

o Determine alternative programming methods to 
accon\modate ISS software . 

o Evaluate alternative hardvNrare configurations, 
considering hardware/sof tv^are interdependencies 
and relative costs, 

o Weigh each concept against anticipated instructional 
support benefits and developinental risk factorB. 

o Result in a "full-support" concept that eventually could 
be implemented. 

The foregoing activities were not accomplished independent 
of those of Phasa III* Indeed, several candidate designs had 
to be examined to evaluate their effectivity as an ISS • 



PHASE III - SYSTEM DESIGN: Figure S suimariEeS the 
activites performed during the design phase. Activities 
in this phase centered upon translating operational system re- 
quirements into a functional systein design which is the central 
subject of the rfflrtainder of this report, 

Recoimnendation for the JUT syllabus were also finalized 
during Phase III. These recommendations could not be finalized 
earlier because the relative merits of system concepts incorporating 
resident coinputer assisted instruction and operator job perfor-^ 
mance aids had to be resolved first* 



EKLC 



21 



2'^ 



NAVTRAEQUIPCEN 76-C-0 0 96-1 



Pillowing development of h«a«are »d "^^^^^uir^onts , 

realistic schedule for the Pfoluction of the impor- 

„are n,odules. ^^l^Jf^^J^^^^rof the ?SS have'n5t been subjected 

tance since many of tne features or tuc^^ 
to the realities of operationaL tramins 



FimLlZlE lUT 

SYLLABUS 

RECOMMENDATIONS 



DEVELOP 
PUNCTIONAL 



▼ 



DEVELOP A 
MINIMUM RISK 



5, Phase III -^System DeBign 



2i 
22 



NAVTRAEQUIPCEN 76=»C-0p96-l 



SECTION 111 

THE TRAINING ENVIRONMENT FOR 
INSTRUCTIONAL SUPPORT SYSTEMS 



nVERVlEW 

The purpose of this section is% 

o To briefly dascribe the instructional enviroiment 
used as the baseline for the analysis of the 
requirements for ISS. 

o Provide an understanding of several specific features 
of the ISS design v^hich were dictated by the assumptiori 
that the prototype field implementation would be in the 
same training environment as that analyzed, 

FRS NAS Miramr, California^ provided the training 

program analyzed* Replacement Pilots (RP) and Replacement Naval 
Flight Officer (NFO) training at VF^124 is intended to provide 
the skills^ knowledges and attitudes necessary for an F14A Fleet 
assignment where aircrew members must perform proficiently in 
all aspects of aircraft operation, weapon utilization and mission 
accomplishment* Training toward these goals is provided through 
a 26-week course of instruction involving academic, simulator 
and inflight training, 

SIMUIATOR TRAlIsINING APPLICATIONS 

RP simulator training at W^124 focuses almost eKclusively 
on the use of the OFT, A procedures trainer was not available. 
The aircrew mission System Trainer (Device 2P112) had not 
been installed during the analysis timeframe. 

The simulator portion of the RP syllabus has three purposes 
which were addressed in a minimum of eleven structured eKeraises* 
The content of each exercise is largely described in the 
Instructor's Briefing Guide document. Each eKercise lasbs>irGm= 
one to one and one=half hours* The three purposes are discussed 
below- 

FLIGIIT FAMILIARIZATION, This involved performance 
of normal procedures^ takeoff and Standard Instrument Departures 
(SID 'a) from NAS Miramar, Simulated flight can be continued to 
an over^the-water controlled airspace, Whiskey^291* The 
aircraft (simulator) can then be flown and maneuvered in the 
warning area to enable the RP to learn aircraft responses, 
control techniques associated with the F14A, the use of cockpit 
controls and displays unique to the F14A, and to practice 
responses to selected f ailures/erTiergencies * Upon completion of 
training within the dedicated area, the aircraft (simulator) is 
flown to a marshal point, and thence to NAS Miramar, where 
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various instrument approaches, final approaches, missed approaches 
and landings are practiced. Prescribed voice proceflures are re- 
quired . 

AIRWAYS FLIGHT-^ This involves normal procedures, 
takeoff s and^ ■stanmrd instruinent departures from MAS Mirainar. 
Flight is continued on various legs of specially designated air- 
ways training routes (India routes) . instrument approaches and 
missed approaches are performed at intermediate Air Force Bases. 
Fuel planning is emphasizad and upon ccipletion of the last air- 
ways leg, various instrument approaches, final approaches, missed 
approaches and landings are performed at NAS Mlramar. A bingo 
fuel profile flight to MCAS Yuma can also be simulated. This _ 
training further enables the RP to learn control techniques unique 
to the F14A, the use of F14A cockpit controls and displays, and 
to practice responses to selected failures/emergencies. Pre- 
scribed voice procedures are required. 

CARRIER OPERATIOWS. This training centers upon 
launch, departure, flight to a marshal point, holding pattern, 
instrument approach, various final approaches, missed approaches 
and recovery. Normal procedures and carrier operations procedures 
are incorporated. Prescribed voice procedures also are re 
quired. Failures/emergencies are not incorporated. 

The OPT is also used for fleet defense. This involved 
integrated aircrew team performance, standoff missile and short 
range missile launches, and tactical and electronic responses to 
various threats. Prescribed tactical communications are re _ 
quired. This application is almost exclusively for Fleet air- 
crew refresher training and NATOPS checks, and requires the OPT 
to be electronically linked with Device 15C9, the rear-seat 
Mission Trainer. The VF-124 syllabus does not require linked 
mode Fleet defense training. However, since this is liKely to 
change with the introduction of Device 2F112, the need to incor- 
porate aircrew training exercises into the ISS was taken into 
account . 

OFT USAGE 

Each of the two OPTs at NAS Mlramar is norrnally scheduled 
to be available approximately 50 hours per week for training. 
A review of six weeks of OFT usage showed a relatively high 
overall utilization. Significantly! 

o 23 percent of OPT simulator sessions were logged as 
scheduled RP training 

o 17 percent of OFT sessions ^ere logged as Fleet use 
and other miscelianeous uses 

o 55 percent were logged as "extra training," wherein 
RPs use the OFT outside of the normal syllabus. 
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These findings were of particular importance in terms of 
incorporating ISS features that could enhance quality and stan- 
dardization of instruction while making maximum productive uec 
of "extra training" time* Typically, an IP is not preBent 
during extra training; however^ with the assistance of a train- 
ing device-man (TD) , the RP can practice flight control , naviga- 
tion^ fuel management/ some comnunication procedures, most 
normal procedures and a plethora of emergency procedures with 
no formal instruction, and with performance feedback derived 
almost solely from cockpit cues. It was felt that a "full support" 
ISS should be capable, to some extent, of compensating for the 
absence of an IP by providing the RP and TD with information and 
system control capabilities that would make possible efficient 
use of the extra time sessions, 

RP AND IP ASRTGMMKi^TR 

Am in most FRSs, a particular student is not assigned to a 
particular instructor, even for sub-phases of instruction. This 
reflected the instructional philosophy of exposing students to 
both varying instructional styles and different approaches to 
problem solving. 

One Qonsequence of this philosophy is that a heavy adminis- 
trative burden is placed on the use of simulation grade sheets 
to ensure continuity of training in all required areas. Although 
inadvertent, it occasionally happens that continuity of instruction 
breaks down and an RP does not receive prescribed training or 
achieve acceptable levels of performance on all objectives. This 
aspect of the instructional context is not unique to VF--124* It 
was felt that a full support ISS could provide useful adminis- 
trative assistance to overcome this problem, 

lUT TRAINING 

VF-124 is not unique in that IPs generally lack training in 
both simulator operation and instructional methods (Charles, 
Willard and Healy, 1975) , The training analysis performed as a 
part of this study showed the following. Instructors Under 
Training (lUT) receive rather informal training in use of the 
OFT, consisting largely of flying the simulator missions several 
times, followed by on-the-'job training in console operation. An 
expanded lUT syllabus recently was developed at VF-124 but, to 
date of this document, has not been formally implemented. Even 
when implemented, it can be expected that heavy instructor work** 
loads will limit expansion and formalization of lUT training. 

The latter point is important in that it directly affects 
the conceptualization of the ISS. The assumption is that it is 
not realistic to count on IP training to compensate for design 
inadequacies of the ISS. On the contrary, an operational ISS 
must be designed to maximize ease and orderliness of operation 
if it is to be used effectively by the IP. 
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INSTRUCTIOi^AL PUIJCTIOWS 

A significant aapthcL o£ the analysia was to establish XP 
and TD ancillary and auxiliary instructional functionB^ and to 
determine which of these would be candidates for automated eupport. 
The following listing suntmiarizes the identifiable functions per- 
formed by the IP during training of an RP on the simulator. An 
asterisk appears by those determined to be candidates for automa== 
tion. 

^Review and evaluate the HP's progress to date. 

*Decide upon training content of the simulator training 
eKercise to be undertaken, 

*PreBent a pre-session briefing covering the instructional 
objectives to be met and the mission plan to be used as 
the training medium* 

*Interrogate the RP on flight control, system and opera- 
tional knowledges required to enable him to benefit 
from the simulator exercise* 

^Provide instruction in areas of RP pre-eKercise knowledge 
weaknesses , 

Provide over the shoulder instruction on cockpit controls^ 
displays^ an procedures. 

Perform plane captain's role by giving hand and arm signals 
to RP during performance of engine atart and post-^start 
system checks. 

*Perform missing crewmember role by reading NFO checklists 
and monitoring RP responses. 

Perform missing (NPO) crewmember role by participating 
in problem diagnosis following system failures, 

*Provide training problem control in keeping with content 
of the Instructor's Briefing Guide. 

*Adjust training problem content in keeping with RP's 
observed performance. 

Communicate system^ procedural and operational knowledge 
to the RP. 

^Provide coaching^ cueing and performance feedback to the 
RP. 

^Insert and/or remove, or comnand TD to insert and/or 
remove system failures. 
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^Vector the RP within a simulated warning area. 

Tnterrogate tha RP on system knowledge* procedures, causes 
and consequences of failures^ flight operationi^ coimnuni^ 
cation procedures^ aircraft operations and operating limits 
and NFO tasks during the training eKercise, 

*Take notes for performance evaluation/ grading/scoring, 
learning problem diagnosis ^ and post^exercise debriefing 
of the RP, 

^Sample and evaluate the RP ' s perforinance in the areas of 
system knowledge^ normal procedures, emergency procedures, 
flight control, navigation, flight operations and voice 
communication procedures* 

^Complete and annotate grade sheets, 

^Perform the following communications^ 

Mission communications 

San Diego departure control 
San Diego approach control 

Airport Terminal Information Service (ATIS) 
Beaver (search and rescue) control 
NAS Miramar 

Clearance delivery 

Ground control 

Tower 

Approach control 
GCA controller 
Missed approach controller 
Intermediate landing sites 
Local area approach control 
Local area departure control 
Local area missed approach controller 
Local area GCA controller 
Los Angeles Center (appropriate FAA sector controllers) 
Carrier 

Carrier Air Traffic Control Center controller 
Marshall controller 

Carrier controlled approach controller 
Bolter control 

Landing Signal Officer controller 
In s tr uc t lona 1 
Cueing 
Coaching 

Performance feedback " ; 

Mission instructions (e,g,, NFO "slow to 320 knots**-) 



^Debrief the RP, sumnarizing strengths and weaknesses in 
his performance, and ascribe possible reasons for them. 
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*Prescribe remedial, extra and ne:Kt training content, 

^Perform post^exercise instructional management record 
keeping. 

The TD assists the IP to operate the device and also per-- 
forms maintenance as required. TDs do not perfoCTa instructional 
functions, but respond to RP requests for system initializations 
and failure insertions or removals during "extra time'^ training 
exercises- The functions that they pe form in operating the 
device are listed below. An asterisk appears by functions which 
are candidates for automation. 

Set simulator cockpit controls to appropriate positions 
prior to the HP's accomplishment of checks preceding 
takeoff * 

Activate the OFT's computers, load the program tapes , 
and perform system readiness and safety checks. 

^Complete the system initialization by entering data 
in keeping v/ith the Instructor's Briefing Guide for 
the eKercise or request by the IP which programs the: 

Emergency manual insertion/removal controls 

Reset control 

Carrier site data 

Ground site data 

Aircraft environmental data 

* Activate and initialize the VITAL-'2 visual system, 

^Respond to IP and/or RP coimnands to accomplish: 

Ground power on/off 
Ground air on/off 

Remove/insert (simulated) wheel chocks 
Insert/remove emergencies/failures 

Operate slev/ing control to reposition the simulator's 
geographic position 

Close down the simulator following training or perform 
maintenance . 

The asterisked IP and TD functions, in conjunction with 
previously discussed auKiliary functions, provided the basis _ 
for deriving the organization and structure for the design of 
the ISS. 
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SECTION IV 

INSTRUCTIONAL SUPPORT SYSTEM 
FEATURES AND CHARACTERISTICS 



OVERVIE^^ 

This section covers: 

o the development of the design concept for a "full 
support" ISS, and 

o the translation of the concept into a P14A OFT ISS design, 

OBJECTIVES 

Identifying and charaaterizing features of a full support 
ISS was not a challenging task. However, developing an 
integrated ISS conceptual framework to organize and implement 
support features proved very challenging because several design 
goals being pursued frequently countered each other, 

A primary objective was to provide for instructional 
fleKibiiity. One need for fleKibility centers on being able to 
modify computer-president syllabi with relative ease and no major 
disruption to system software, so as to keep pace with changing 
instructional requirements. This translated into a requirement 
to organize the computer-resident syllabus content in a highly 
modular framework. Such that, syllabus modules could be changed 
without disruption of the resident syllabus, 

A second related objective was to develop a system structure 
that would accept the broadest possible spectrum of instructional 
decision making. One end of this continuum is characterized by 
the highly standardized, or canned check ride. The structure ^ 
also had to accommodate automated decision making characterizing 
adaptive training. Finally, IP decision prerogatives at the 
beginning of each simulator session and during the session had 
to be accommodated in a manner that would enable IP's to tailor 
automated instructional support to daily needs as they arise. 

Finally, the system structure had to be flexible enough to 
respond to the total spectrum of training tasks that any RP 
might specify for extra session training. These could cover the 
spectrum from canned missions through self^paced automated 
adaptive training, through practice on particular flight control 
or procedural tasks. 

Concept transportability also had to be taken into account. 
This required anticipating the extension of ISS applications 
beyond the analysis reference point established in the training 
environment. Thus, other mission categories, crew position 
training devices, anticipated instructional support requirements. 
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and integrated aircrev/ training applications had to be con^ 
sidered/ Feedback will have to provide the extent to which 
concept transportability will have been aGhieved * 

The requirement that the ISS also support instructional 
research did not prove difficult conceptually. The need to 
maintain automatically^ data files identifying the utilization 
(or lack thereof) of ISS features was established to provide one 



the utilization files will provide inf o^xiiation of value for 
developing and refining adaptive training logics* This 
information will be based upon modeling of IP instructional 
behaviors as reflected through the manners in which IP's call 
upon ISS in relation to student progress and performance. 

The need to support automated performance measurement and 
scoring research also was recognized. Automated , systems can and 
should'measure RP performance at a finer level of task definition 
and, typically^ using a broader spectrum of measures than is 
practical with a manual measurement and grading system. Creative 
measure analysis and definition can go a long way toward defining 
meaningful automated measurement. However, the need was recog-- 
nized for empirical measurement research to develop minimum 
measure sets for various tasks, and particularly to develop 
scoring algorithms for evaluating task performance at finer 
levels than is commonly practiced in training simulations. 

The need for research flexibility in automated training 
problem development and modification also had to be accommodated 
in the overall system structure. It is assumed that adaptive 
logics will have to be developed empirically from logics 
initially derived by analysis. The impact of this need had to 
be accounted for in software architecture. It also played a 
role in defining the scope and character of basic instructional 
units that comprise the computer resident syllabus* 

A paramount goal was to develop system concepts that^ 
hopefully, would be responsive to the previously described needs 
and would, at the same time, foster user acceptance. This 
requires that system support features had to have a high 
likelihood of providing meaningful instructional support in an 
operational training environment. Thus, the selection of 
support features and the characteristics of their operation had 
to consider the IP and the TD as the system user(s). In this 
content it was obvious that research capability of the ISS, 
although necessary, could not pace the system's conceptualization. 

Finally, evolving a highly straightfoiward, logically 
organized, relatively easy to use man-system interface for IP's 
and TD*s was considered absolutely essential for user acceptance 
and, therefore, ISS utility. It was recogniEed that the inter-- 
face would have to enable IP'r. to obtain the type and amount of 
instructional support desired with considerable ease. A 




It also is anticipated that 
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control-display or procedural wilderness simply had to be 
avoided. As a result, all candidate features / characteristics 
and system operational concepts had to be evaluated repeatedly 
for inipacts on the type of Tnan^system inter faneB that might be 
required to exercise them, 

A focus was needed from which to initiate development and 
analytical evaluation of an automated adaptive ISS. One point 
of focus that proved workable was to define and scope the 
modules of instruction to be accomplished and supported* The 
resulting "task modules" are discussed subsequently, A second 
point of focus was to develop a basic structure within which to 
organize support reatures and capabilities in a hierarchical 
manner. These subsequently became system operating modes, which 
are discussed below. 

TASK riODULES 

Task modules (TM) are individual programming units which 
define the training objectives in the computer-president syllabus. 
They are the lowest common denominators with which instructors, 
system algorithms or adaptive logics can create training 
exercises . 

The TM concept is central to ISS flexibility and growth 
potential. Training exercises are built by selecting and 
organizing TM's which represent training objectives that a 
student has yet to achieve. This provides flexibility for 
efficient self-pacing, A master listing of all TM'a is 
maintained in a system file. Content of the file can be changed 
to reflect changing instructional requirements which the system 
is to support* Existirg TM's can be modified to add or delete 
performance measures, change proficienay standards, or make 
modifications to any of the elements that define a TM, RP 
progress in achieving criterion performance on TM's is maintained 
in the system to allow for identification of objectives yet to be 
achieved, for planning purposes. 

Three types of TM's are required: 

o Flight profile TM's, which are mission flight profile 
segments , 

o Procedural TM's, which are the various normal and 
emergency procedures that can be simulated* 

o Tactical TM's, which are tactical engagement training 
objectives for use in a rull mission ISS, 

A further characteristic of TM's is that procedural TM's, 
such as emergency/failure modules, can occur simultaneously with 
a flight profile TM or tactical TM, This can be done by 
associating procedural TM's to "hooks" defined in flight or 
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tactical modules. Procedural modules also can be exercised when 
predetermined initiating conditions have been met. They also may 
be manually initiated. 

Module sizing was a significant consideration. Training 
objectives can be specified at almost any levels ranging from 
iuacro to microscopic. Procedural TM^s sized themselves; each 
procedure comprises a module. Flight profile modules required 
sizing decisions. It was decided that TM's would be sized in 
keeping with the manner that pilots typically view a mission. 
Examples of TM's sized in this manner are: takeoff / departure , 
individual airways legs^ approach^ final approach and landing* 
Separate modules were then established for each type of takeoff, 
various departures^ a spectrum of airways legs, different 
approaches^ final approaches and landings. For training 
exercise development based on current training practices at 
^--124^ a total of 88 flight profile modules were defined. 
Normal procedure and flight profile TM's are presented in 
Appendix A. Emergency/failure modules are presented in 
Appendix B. 

Tactical modules were not defined. Conceptually, however, 
each tactical module would consist of an engagement. The 
modules would define threat types, numbers, altitudes, speeds, 
and additional information characterizing the threat to be coped 
with during the engagement. This approach to sizing is ideal 
for within-session adaptive problem control because subsequent 
threats can be selected and instituted based upon crew perform- 
ance in coping with prior threats, within the session as well as 
during previous sessions. 

The approach taken to TM sizing further defined characteris- 
tics of the modules. For example, a single module may incorpo-- 
rate more than one performance measure or proficiency standard. 
This is particularl}^ true of flight modules, because many are 
made up of more than one flight segment. For example, a 
Seawolf -Seven standard instrument departure from NAS Miramar 
contains four discrete flight segments^ 

o Climbing right turn to 300^ magnetic to intercept 
NKX TACAN Radial 2 80 

o Intercept 280 radial at 2,000 ft. 

o Fly outbound 280 radial at 2,000 ft, to Seawolf 
(NKX DME = 7 mi,) 

o Climb outbound on 280 radial to W-291 boundary 
(NKX DME - 31 mi, ) 

Certainly, such fine cut flight segments can be construed 
as performance objectives and, hence, as training objectives. 
However, doing so' would have extracted them from any meaningful 
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operational context. Further^ assembling training flight 
profiles out of such small units would be an unnecessarily 
burdensome human task as well as a compleK machine task. 

Furthermore^ it was recognized that task modules also could 
he defined in ways that would make them too encompassing* For ex- 
ampler a flight module could be defined to consist of a particular 
departure in combination with a particular airways route. If 
this were the case, IP's and system algorithms could only call 
upon the "combined" module^ even if training was required only 
on a portion of the module, such as the departure. 

Accordingly, the following information elements were established 
to define a task module. The information elements were derived 
from an analysis of information the ISS would require to support 
instruction at the task module level. The resulting elements 
organize easily within the definition of a training objective, 
i*e*, specification of behaviors to be trained^ conditions of 
performance, and standards of proficiency* The additional 
category of systein information was added to accommodate informa- 
tion requirements unique to automated instruction. 

o System Information 

Module entry conditions 
Motdule teriTiiriation conditions 
Base data, shore 
Base data, ship 
visual system data 
7; Graphic display data 

Hook definition data, for associating failure 

modules with flight or tactical modules 
Controller models to be used 
Cueing message data 
Instructor alert message data 

o Conditions information 

Environmental data, atmospheric and oceanographic 
Requisite aircraft configuration data 
Requisite aircraft systems failed 
Aircraft initialization data 

o Task Information 

Failure module designation 

Failure insertion conditions 

Failure removal conditions 

Procedural steps for coping with failure 

Normal procedure module designation 

Normal procedure procedural steps 

Flight module dosignation 

Flight segment (s) definition data 

Tactical module designation 
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o Task Information (cont'd.) 

Threat characteristics data 
Mission communication 

ConTmunication originator - ISS, IP or RP 
communication initiating conditions 
Communication message content 

Conmunication delivery medium, display for IP 
or voice generation 

o Measurement information 

performance dimension designation (s) _ _ 

performance measures - measure start/stop conditions, 

parameters, desired values, transforms 
proficiency scoring criteria data - jigorithm for 

converting performance measures to a score 

consisting of one of five categories 
Algorithm designation for combining scores within a 

module 

rss MnnTO 

ISS operating modes evolved out of the recognition that 
total system capabilities had to be organized. Initial attempts 
to identify ISS modes centered upon clustering various 
instructional support features Into categories. It soon became 
evident, however, that this strategy was resulting in system 
operational structures that bore little direct relationship to 
operational training. 

A further strategy resulted in the operating modes that are 
presented below. This strategy involved definition of system 
modes that encompassed the continuum of instructional decision 
making, ranging from detailed planning of the instructional 
content of a simulator session through relegation of training 
content decisions to the computer. A second element of the 
strategy was to conceive of modes in a manner that would provide 
instructors with considerable latitude to change to modes 
different from the one selected at the beginning of the simulator 
session. This was felt necessary to ensure that ISS would be a 
flexible, responsive support system. The following modes 
resulted . 

COMPUTER ASSISTED TiAlsIUAL MODE. , The^ Computer ■ 
Assisted Manual (CAM) mode will require the greatest instructor 
involvement in planning the content of a simulator session. As 
with all modes, instructional content is selected from a 
computer resident syllabus containing all task modules. 

In the CAM mode, the IP (or TD) selects individual task 
modules for which he desires automated instructional support. 
This capability allows the IP to draw upon automated support 
while tailoring the content presented to the RP. CAM is 
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eKpected to have research utility in that automatic recordiiig 
IP selection of this (or any other) mode^ along with the training 
content (modules) selected^ should provide valuable information 
for subsequent use in dQveloping and refining adaptive training 
logics * 

From a training standpoint, for example, if an RP is having 
difficulty adequately perforniing TACAN approaches, the IP can 
call various TACAN approach modulf^s resident in the syllabus. 
This, in turn, would enable him to obtain automated measurement 
support for use in diagnosing the RP-s perforitiance problem. 

In a different instance, an RP may wish to practice carrier 
landings during an "extra session." In this case, the TD could 
call appropriate approach or final approach modules with related 
voice controllers and "enable" reset to module entry conditions 
for repeated trials. 

The CAM mode also enables the IP to request automated 
support in the area of procedures monitoring. For example, the 
mode enables him to select automated support for monitoring RP 
performance relative to one or more normal procedure modules. 
Similarly, it provides him with total flexibility for selecting 
individual and multiple emergencies/failures to be inserted^ 
monitored and removed. 

The C^\M mode should have considerable utility for tactical 
training applications. Tactical engagements usually are 
relatively brief, and a number of engagements can be incorporated 
into a unit of simulator training time. The CM! mode provides 
the instructor with ^."ery convenient and responsive means of 
selecting and initializing subsequent engagements based on 
student prior performance, 

INSTRUCTOR SKLECT HODE , The Instructor Select (ISFT.) 
mode is much like the CAM mode in terms of training content 
decision making, ISEL^ however, will allow the IP to select 
from a list of total mission profiles, each profile consisting 
of a pre-^determined structure of flight modules organized and 
sequenced into a meaningful mission context. Selection of the 
ISEL mode allows the IP to quickly and easily draw upon autoinated 
support for the flight portion of the mission, while retaining 
decision prerogative on, for example, emergencies that he wishes 
to have the student cope with, 

ISEL incorporates two ways of inserting or removing 
emergencies. Firstly, to select emergencies from a computer 
generated display listing^ and to specify the conditions for 
automatic insertion and removal. Secondly^ to manually insert 
and remove failures vi 1 the ISS console. 

Similarly, automated support in monitoring and evaluating 
the performance off normal procedures can be obtained by selecting 
normal procedure modules from a computer generated display listing. 
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For training in tactics^ the ISEL mode would allow the in- 
structor to select from alternatives / pre-determined sets of 
tactiaal scenarios, each scenario consisting of a series of 
gngagements made from tactical task modules, 

CAf4WED MISSION riODL. The CAirwED mode v/ill build upon 
ISEL by providing for totally pre-programmed missions and events. 
rhuB^ flight, normal procedure^ emergency and tactical modules 
□omprising a total training exercise will be specified in advance 
as the instructional decisions of this m^de center exclusively 
on Selecting the canned mission to be used* 

In practice, it is anticipated that two categories of canned 
nissions will be required. The first category will be missions 
iesigned to emulate present simulator training exercises and the 
second category will be NATOPS evaluation missions, which, should 
be highly standardized and objective, 

A canned mission capability is desirable for several reasons 
as follows : 

o It provides instructional personnel with easily acGessible 
full system support to accomplish training in a highly 
structured version of how simulator training is presently 
structured, 

o It provides instructional users, with a minimum training 
involvement opportunity, to observe a spectrum of ISS 
instructional support capabilities and features. This 
could be particularly beneficial to instructional peraonnel 
when they are first learning how to use ISS, 

o It enables the Rp , with the assistance of a TD, to 

utilize the spectrum of ISS capabilities during ''extra 
training " sessions * 

o It provides the student with the opportunity to self'-test 
his performance capabilities, at least within the training 
content of the mission selected* 

o When various adaptive training logics become operational, 
their effectiveness likely will be enhanced if training 
is at least started from a standardized baseline* 



Note that ISS avoids the rigidity often associated with canned 
mission scenarios by building each mission from computer-resident 
task modules. As discussed previously, the content of any module 
-an be altered, and new modules can be created , Simrlarly, algo- 
rithms that draw upon the modules to create canned training exercises 
can be modified. Thus, content of canned missions can be modified 
^ith relative ease. Additionally, the capability to create addi- 
tional canned missions exists* 
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ADAPTIVE OPE^TIOW MODES* Adaptive operation modes 
will be developed empirically, after sufficient data and ax- 
perience have been obtainGd on all lower order modes. However^ 
at this time/ the envisioned functional characteristics of 
adaptive operations can be described* Basically ^ adaptive mode 
operations will audit the passing and failing of specific learn- 
ing objectives / defined by task modules , and attempt to create 
missions from structured lists of objectives not yet passed. 

The information structure that is needed by adaptive mode 
operations is illustrated below. Each learning objective is 
listed in a prioritized order, with the most important or most 
difficult objectives occurring generally at the top. This list 
will point to the task modules that addresses the objective. 
Each learning objective will point to a companion criteria file 
that will indicate, as a minimum^ the score required for passing 
and the minimum number of passing trials required to meet each 
objective. 
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The minimum information set for flight and tactieal modules 
will be similar to procedure modules/ except that an additional 
file that organizes groupings of modules may be required for 
logical flight continutiy. Also, each mission organiaation must 
have associated with it a set of emergency insertion criteria that 
are permissible. That information set is illustrated as follows i 
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Thus, at this point, the system knows what needs to be learned, 
a number of ways it can ba organized, and the criteria for achieving 
Ihe^Irning objectives. The various adaptive modes are desarrbed 



below 1 



ADAPTIVE-BETWEEN MODE. The adaptive-between (ADBET) mode 
will use adaptwe training logic that operates between 
simulator sessions only. It accesses information identify 
ing whdch training objectives have and have not been met 
by each RP. It derives a list of objectives that have 
not been passed. Next, it constructs a simulator flight 
profile or series of tactical engagements from lists o£ 
logical flight or tactical module organizations which 
reflect unsatisfied training objedtives. Failure modules 
are attaohed to the resulting flight events. ADBET is 
hierarchical^ e.g., satisfaction of failure objectives 
can be made more important than satisfaction of flight 
objectives, within limits. 

A fairly sophisticated set of rules will be required to 
optimize the achievement of different categories of 
objectives and associated task modules. For example, 
some flight modules (e.g., carrier operations "'Ovules) are 
not amenable to emergency procedure training. Thus,_ADBEr 
logic may be required to create "composite missions, 
such as half of a mission in a simulated warning area, 
followed by transition to carrier operations. This would 
be the case, for example, where flight objectives were 
being met at a rate faster than emergency objectives. 
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Development of rules to accomplish between session 
adaptation were not addressed during this study. 
However^ the student's position in the syllabus^ the 
required procedures which precede flight training^ 
the number of objectives passed (or yet to go), and the 
limits of "normal" student progression will have to be 
considered in order to determine even a rudimentary 
set of rules, 

ADBET also will require rudimentary algorithms which 
addrees alternate training time-optimal pathways through 
the syllabus. It is possible^ for example, that some 
emergency or flight training objectives may be "post-' 
poned" until a later time if achievement of them is 
impeding student progress, 

ADBET logic is not intended to be infinitely adaptive. 
For example, only logical groups of flight modules will 
need. to be considered for constructing mission profiles, 
These groups will likely fall into the categories of 
flights in warning area, India routes, departures, 
approaches and final approaches, carrier operations and 
tactical exerciseB, 

ADAPTIVE-WITHIN MODE, The adaptive within simulator 
session (ADWIN) mode will do everything the ADBET mode 
does, only it will operate within a simulator session. 
Thus, real'-tim^v or very near-real time decisions will 
be required/' ADWIN is conceptualized to re--organize 
the simulator mission (if necessary) as a function of 
the performance achieved on the prior completed emergency, 
flight or tactical module. In reality, it is probable 
that ADWIN will operate most effectively in relation to 
emergency procedure and tactical objectives. 

Given prioritized lists of learning objectives, ADWIN 
initiates a simulator mission using ADBET logics. If 
a higher priority objective is not passed, it is brought 
up again in place of a lower priority objective later 
in the mission, A set of contingencies is required to 
reasonably distribute objectives of like priority so 
that one objective does not repeat to the exclusion of 
everything else. 

Due consideration will have to be given to the within- 
session change of flight modules. Only limited flight 
module adaptation should be permitted, within the context 
of the mission. For example, a substandard take-off 
and departure may be worthwhile repeating, at least after 
a certain stage of training. Certainly, approaches may 
be repeated in favor of some other flight modules that 
can be postponed until later or the next simulator 
session. Finally, flight maneuvers that are important 
for the next aircraft flight may be repeated in favor 
of less critical maneuvers. 
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ADWIN's adaptatio.. for tactics appears quite natural, 
because one may, change the nature of the next tactical 
exercise, providing the exercise remains within a 
reasonable mission context, 

o SELF-ORGANIZING MODE, The self -Organizing (SELFORG) 
mode is envisioned to be upward compatible with both 
adaptive modes, SELFORG will perform audit trails on 
the operations of ADBET and ADWIN, and adjust control 
algorithms (algorithms which cortrol the selection of 
exercises) in accordance with the probability of success 
that has been achieved by students passing through each 
of the specific exercises or individual modules. SELFORG 
will eventually preclude unproductive pathways and in 
essence^ it will perform housekeeping ^ but cannot add 
new exercises* 

A SELFORG capability will have to be implemented through 
offline data analyses performed by a training research 
specialist. However, as a result of current research, 
ways may emerge to implement controller algorithms that 
can perform all or part of a normal audit trail operation. 

Given the current state of the art in automated instructional 
support, it is likely that a first generation XSS would incorpo- 
rate only CAM, ISEL," CANNED and a preliminary ADBET capability. 
ADWIN and SELFORG mode capabilities require additional development 
before meaningful operational applications can be made. In par- 
ticular, methods of joint problem adaptation of flight and proce- . 
dural task combinations and procedural and tactical task com-- 
binations require considerable ISS data collection before models 
can be developed. 



SUPPORT Filatures 

The balance of this section describes other categories of 
ISS features many of which v;ill be independent of mode, since 
support capabilities such as performance measurement and scoring, 
RP cueing, and use of automated voice controllers, are specified 
at the task module level* 

The material herein is intended to simplify the presentation 
of support feature information and is not intended to dictate 
software organization of a full support ISS* 

DATA FILES, A num.ber of different data files v;ill 
be required for efficient planning and accomplishment of a 
simulator training session. These arei 
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O STUDENT HISTORY FILE* h master computar-resident module 
file will contain a listing of all task modules that are 
associated with the learning objeGtives that RP classea 
are to accomplish through training in the simulation. It 
defines the computer-resident syllabus, and can be 
modified as required* As performance measurement and 
Bcorlng data indicate that individual RPs have - achieved 
criterion performance on a task module, note is automa-^ 
tically made of this in the master file* What results 
is an identification of modules on which criterion 
performance remains to be demonstrated* This information 
is maintained separately for each RP. Content of the file, 
when accessed by the instructor or adaptive logics, 
provides a basis for efficiently structuring the content 
of simulator sessions by providing an ability to focus on 
objectives yet to be mastered. The date of achievement 
of each module by each student also is noted to provide 
for assessing rate of progress* 

O STUDENT AND CLASS PILE. This file will contain _ individual 
student background data and is designed to provide in-^ 
structors with ready access to relevant student back- 
ground information which can be useful in planning 
simulator training session content. Content of the file 
can be accessed and displayed at the class level, in 
addition. Summarized at the class level i content of the 
file provides instructional management and researchers 
with diagnostic information to assist in assessing 
differential group performance at the class level- 

o MEASURES COLLECTION FILE. An automatedr adaptive 
instructional support system will require the use of 
valid criteria for acceptable and unacceptable levels 
of student performance. Additionally, valid diagnostic 
measures that can pinpoint student performance defi- 
ciencies in manners that allow for attributing probable 
causes also are required* These requirements exist both 
for human interpretation of student proficiency and 
diagnosis of performance problems, and for automated 
adaptive training logics designed to accomplish the same 
goals . 

The many advantages previously described for sizing task 
modules bring with them a requirement for empirical 
measurement research and development. The various task 
modules are of a rather precise nature. Each will require 
measuring a number of performance dimensions. Analytic, 
or best guess, measure analyses must provide the starting 
point. Empirical work will be required to modify and 
validate the initial best guesses, both with respect to 
proficiency assessment and performance problem diagnosis. 
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A considerable spectrum of performance standards wilX 
be required. For eKample, some task modules, such as 
flight TMs, contain more than one measurement segment, 
as described previously. Others, such as procedural 
TMs require measurement and assessment of highly 
different dimensions of performance. The asseasment of 
performance of a procedure, for eKample, requires 
measurement and scoring of responses, together with 
measurement and assessment of the occurrence of required 
procedural steps and the sequence occurrence o£ at 
least highly critical stages. 

The purpose of the ISS measure file is to collect data 

to establish objective standards of acceptable performance 

as well as diagnostic information at the task level. 

The value of the research and development made possible 
by the file falls within several areas. One is to 
replace initial best guess performance standards with 
empirically derived standards. This should enhance user 
acceptance of ISS proficiency assessments because the 
number of scores that instructors or students would^^ 
question should diminish, at least in tneory. ^.esuxwa 
of the research hopefully should guide measure analyses 
for aircrew training applications beyond an initial ISb 
installation. The functioning of automated adaptive 
training logics should be enhanced through use of data 
provided by the measures file. 

Measures data will be voluminous and will have to be 
recorded for off-line analyses to develop performance 
norms and diagnostic measure sets. Each measure will 
have to be highly qualified, at least m terms of the 
following dimensions i 

Task module designation 

- Task(s) (measure segments) within the module 

- Measure source (student or IP Identification) 

_ Date and time of day, to allow for relating 
performance to prior executions by the same 
measure source 

PERFORMANCE NORMS FILE. This file is designed to contain 
a current listing of performance normative data for use 
by scoring algorithms in scoring proficiency at the task 
module le?el. Initially, the file will contain best 
quess data. Content of the file can be updated with 
empirically derived normative data following empirical 
measurement research and development. 
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The file will have to contain two classes of normative 
data. One class will be quantitative breakpoints for 
scoring individual performance dimensions within a 
task module. The second class will be quantitative 
breakpoints for a use in developing an overall module 
score for use in assessing proficiency at the module 
level. 

An intriguing alternative to developing normative data 
through off-^line analyses and human judgements is auto- 
matic generation of norms by system software* Automatic 
generation of norms often is assumed in higher orders 
self organiEing automated adaptive training structures. 

The ISS concepts and functions set forth in this report 
do not incorporate automated norm generation for two 
reasons. First, the ability to do so in a system as 
inherently complex as ISS remains a researchable issue* 
As automated instructional support system applications 
in operational settings are in their infancy^ initial 
user acceptance is of prim.ary importance- The tschnology 
that can be brought to bear in operational training 
settings through such systems has yet to be demonstrated 
to instruct ional and training management personnel* In 
this contexts incorporating a competitive^ computer-based 
capability with NATOPS or other Navy standards of per-- 
formance may be premature, 

o INSTRUCTOR ACTIONS FILE. Its purpose is designed to 
automatically record significant instructor actions 
involving ISS. These arei modes initially selected; 
mode changes mads during the course of a simulator session 
optional support features selected ^ and support features 
that normally would come into use automatically but were 
de=-selected by the instructor. This information is ampli-- 
fied with instructor and student identification informa- 
tion, together with date and time of day* These data will 
provide the mechanism for relating significant instructor 
actions to student performance and history information* 

Over time, analysis of significant instruction actions 
will serve four purposes; firstly , it will objectively 
identify relative frequencies of ISS feature usage; 
secondly, it will provide a means for taking instructor 
actions relative to student performance into account for 
building or refining adaptive logics; thirdly, it will 
provide a quantitative source of feedback on the effec- 
tivenesa of instructor training in ISS usage, and forthly, 
it v/ill provide a source of feedback on ISS acceptance by 
instructors * 

PRE-SESSION SUPPORT* ISS is conceived to provide both 
ancillary and auxiliary instructional support in preparation 
for the conduct of a simulator training serssion* Pre-session 
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support centers in three areas i firstly, mission planning; 
secondly, computers-generated pre^session student briefing content 
that is based on session instructional content identified during 
planning, and thirdly, computer based pre-'Session readineas test- 
ing* The latter is intended largely to replace the pre'-session 
interrogation of students by instructors, and is expected to 
have direct application during "extra session" training when an 
IP may not be present. 

Q MISSION PLANNING* From the ins+^ructional user's stand- 
point, ISS is organized to provide him with student 
performance history information, including objectives 
yet to be met. Displaying a list of modules on which 
"criterion performance is yet to be achieved" is designed 
to provide objective focus for session planning. 

Following a review of student performance history infor- 
mation, the nsKt planning decision required will be the 
selection of an ISS mode of operation, ranging from CAM 
through various adaptive modes* In CAM, the instructional 
user selects one or more task modules for which instruc- 
tional support is required. These are not limited to 
modules on which criterion performance has not been 
achieved. They can be any modules. In ISEL, the user 
selects a total flight profile or series of tactical^ 
engagements as a starting point* If he has used avails- 
able planning information optimally, the selected profile 
or engagement will maximize opportunities to achieve 
criterion performance on yet unmastered task modules. 
The basic ISEL unit can then be amplified with proce^ 
dural and/or emergency modules at the discretion of the 
user. CANNED mode exercises are selected in a similar 
manner to ISEL, If an adaptive mode is selected, sys- 
tem logics select modules to be incorporated into the 
training session* 

A mission builder function will then be called upon. 
The mission builder takes mission planning inputs from 
the instructional user (CAM and ISEL modes) , algorithms 
for the CANNED mission plus adaptive logic which may 
have been selected, and creates the training exercise 
from the modules that have been specified, 

A mission editor function is then called upon. The mission 
editor checks for module-tO"»module compatibility. In doing 
so, it determines whether eKisting conditions for a preced-» 
ing flight module, such as altitude^ heading for speed, are 
compatible with entry conditions for thenext flight module 
and any discontinuities are displayed* For. eKample if an 
airways leg flight module and a final approach flight modul 
were selected, a discontinuity may exist, as the termina- 
tion of the first would not necessarily have to coincide 
in time and space with the beginning of the second. In 



NAVTRAEQUIPCEN 76-C-0096-1 



the event of incompatibility, the IP is required either 
to accept the incompatibility or modify his initial plan- 
ning to eliminate it* 

A second type of mission editor uompatiblity check is to as- 
sess compatibilities of procedure modules, both normal pro-- 
cedures and emergency procedures, with flight or tactical 
modules in which they are to occur or which follow them. 
Logical inconsistencies are identified. For example, it 
is inconsistent to plan an engine hot-start emergency 
for occurrence during a flight module when both engines 
are anticipated to be running normally. Similarly, a no- 
flaps landing requires prior failing of systems that are 
used for operating the flaps. 

In this respect, it must be noted that flight task modules 
identified in Appendix A as having instructional meaning 
in the VF-^124 context, incorporate different flight 
module designations for situations where certain prior 
emergency conditions exist. Final approach is an example 1 
different final approach modules are identified for flap 
versus no--flap. This is necessary because standards of 
acceptable flight control performance may be different 
for the two types of landings and such standards are con-- 
tained in individual module definitions. Measurement and 
scoring research will also require maintaining performance 
measure data separately for such modules. 

The mission editor also can be viewed as a training tool 
as it will sensitize the new ISS user to potential prob- 
lems he can create while planning a mission if insufficient 
attention is not paid to details in the use of CAM, ISEL 
operating modes. 

Furthermore, the mission editor function also will be 
beneficial in developing CANNED missions which must be 
completely debugged before they are made available to 
instructional users on a day--to-day basis* Similarly, 
adaptive logics may draw upon the power of this editing 
function. 

The planning activity, which identifies the content and 
the seguance of the planned simulator session, provides the basis 
for two optional, pre^sesssion instructional supports: a computer 
generated pre^-session briefing, and a computer^generated pre-session 
readiness test. 

o PRE^SESSION BRIEFING. At the ISS user's option, a computer- 
generated pre^session mission briefing can be requested. 
Content of the briefing is patterned after present instructor 
briefing formats, which outline the mission scenario. The 
computer-^generated briefing identifies the normal proce- 
dure, flight and tactical task modules, in sequence, that 
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comprise the mission plan. Emergendy modulea incorporated ' i 
into the plan are listed separately and in alphabetical 
sequence to minimize student anticipation o£ when they 
are apt to occur. It is expected that the briefing will 
be electronically displayed and a hard copy made. 

o PRE-SESSION READINESS TEST. It is a common and useful 
practice for instructors to interrogate students on air- 
craft operational limits, effects of failures and malfunc- 
tions, stimulus patterns associr ;ed with various aircraft 
states, operational rules, and other elements important 
in the context of the upcoming training session. This 
can be done following the mission briefing. The intent 
is to identify mission-critical knowledge weaknesses so 
that remedial instruction can be given prior to the 
mission. The full-support ISS incorporates this function 
with the objectives of standardization and providing for 
mission readiness testing in the absence of an instructor. 

Following receipt of the mission briefing by the student, 
ISS can be coirmanded to draw upon an item pool and develop 
a pre-mission test based upon the briefed mission that the 
student is to fly. The test is administered and scored by 
ISS console. A multiple choice format is anticipated. 

After the test has been taken, the instructor, if present, 

can review the results and provide necessary remediation % 

prior to commencing the mission demonstration. 

The number of test items and the logic for their selechion 
is not addressed here. It is unlikely, however, that one 
test item should be administered for each task module that 
has been planned for a simulator session. The resulting 
items could be both excessive and redundant. 

The question of the utility of providing a pre-session demon- 
stration of planned mission events, either in the cockpit or at 
an ISS console, should be answered with respect to specific ISS 
applications- Demonstration capabilities are not common in 
training simulators presently in use. Thus, there is a dearth 
of operational feedback on the utility of demonstrations as a _ 
function of mission task characteristics and requirements. Addi- 
tionally, no directly applicable basic research is known to exist. 

The utility dimensions of pre-session demonstrations involv- 
ing an ISS or a training simulator must be questioned. Having 
a computer operate cockpit controls to demonstrate procedures has 
little apparent training value and would require controls that 
could be operated remotely. Furthermore, in the tactical train- 
ing area, it must be remembered that tactical maneuvering and 
weapon delivery decisions must be influenced by adversary offensive 
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and defensive actions. Demonstrating one possible way of com-- 
pleting a tactical eKercise in a simulation could be of little 
practical training value. However, a capability to quickly 
re--set to defined initial conditions, as ISS enables, provides 
the opportunity to increase the number of missions conducted 
during a session. For these reasons, a demonstration capability 
is not recoTOiended for initial ISS applications. 

TRAINING SESSION SUPPORT . Many of the teatures and 
charaateristics of ISS support the conduct of instruction during 
a simulator training session • They are intended to be of inetruc-- 
tional value to both instructors and students. Features and 
oharaateristics directly relating to the conduct of training are 
described below, 

o Automatic Problem Initialization. Following the comple- 
tion of planning activities, the entire training program 
will automatically initialize. ISS monitors pertinent 
host simulator systems and data parameters to determine 
when entry conditions for the first task module have 
been met. From this point on^ system operation can be 
totally automatic within the design bounds of ISS* 

^ Automatic Module Secfue nclng, Sequencing of subsequent ^. 
task modules vrill be "autortiatic. As above, module entry 
conditions data are monitored so that ISS can determine 
when to begin operating on the module's program. 
Similarly/ module exit conditions are monitored so that 
an on-going module can be closed out when it has been 
complteted , 

o Instpuctignal Monitoring Information • Two CRT displays 
wril provide the instructor-system interface through 
which all mission information can be called upon. 

Section of this document addresses the physical descrip- 
tion of ISS, including the man-machine interface. It is impor- 
tant to establish here, that the instructor-Bystem interface will 
be built around two CRT displays. 

One display is a graphics display that allows monitoring , in 
real time, of the following f cross-country flight path history, 
flight path history within a simulated warning area, approach and 
final approach profiles, and tactical flight history. This capa-- 
bility is provided to allow monitoring of mission progress rela= 
tive to the mission plan. Content of the display is defined 
largely by the definition of the flight or tactical module that 
is active at the time, 

A touch panel alphanumeric display is provided for instructor 
command of iSS and for ISS display of instructional monitoring 
and other information. Using the display, the instructor can 
review task modules comprising the session plan and receive infor- 
mation regarding which modules have and have not been performed 
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to criterion* Also at his option, he can review performance 
scores on completed modules, and request more detailed diagnostic 
measurentent information on completed modules* 

InBtructore also will be able to participate in scoring^ 
student performance through the man--machine interface. Scoring 
of student communication protocols and perf orinarice is assumed to 
be manual, pending further development of computer speech under-- 
standing system technology, A scoring format is displayed upon 
instructor request. He may then identify the coinmunication 
module and enter a score. The instructors-generated score is 
used to assess the student's achievement of criterion performance* 

For research purposes, and to facilitate initial refinement 
of scoring criteria, instructors also will be provided with the 
option of overriding computers-generated scores. These data will 
enter the student » s file for the module scored* This feature is 
intended only for use during the initial period of ISS operation. 

A limited inter-instructor memorandum capability also is pro-- 
vided. This uses a fixed format display field. Instructors can 
designate comments that apply to student perf ornianae or attitude. 
These comments can be called up subsequently only by instructors, 

o Synthesiz ed Instructor . The ISS will incorporate a com-- 
pu^feTea^voi c e ^g^ nlra t i on^ system. This capability xs 
used in two ways, one of which is to relieve the instructor 
from many routine instructional communications, as dis- 
cussed below. 

If enabled from the ISS console, computers-generated eval- 
uation feedback voice messages can be transmitted to the 
host simulator cockpit and to the ISS console. This 
relieves the instructor of having to provide feedback. 
Also, auditory display of the messages at the console 
capitalizes on the voice generation system as a supple- 
ment to the electronic displays- Presenting this feed- 
back to the cockpit also provides the student with know-- 
ledge of results information during unsupervised "extra 
session" training . 

Student prompting messages also are available if the capa- 
bility is enabled from the console. Prompting messages 
are initiated by failure to respond within a predetermined 
time to insertion of an emergency, failure to make major 
required flight path changes, and similar events. 

A full support ISS will incorporate the option for a brief 
in-cockpit mission summary briefing using the voice gener- 
ation system. Its primary purpose" is to provide a synopsis 
of the content of CANNED missions during unsupervised 
"eKtra training, " 
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An additional use of computer-generated voice messages 
Is to alert both the student and the instructor to near 
real time changes in session training content resulting 
from operation of wlthin--sesslon adaptive training logics 
(ADWIM) , In this case, the task module selected by the 
computer would he announced shortly prior to initiation. 
This use of the voice generation system also is select- 
ible from the console. For example, advising the student 
of an upcoming emergency or the nature of the next tacti- 
cal threat could prove counterproductive if the voice 
generation to the pilot was not curtailed. 

Use of the voice generation system for delivery of coach-- 
ing messages was considered but not adopted* Although 
technologically possible, considerable difficulties can 
be anticipated in achieving agreement among instructors 
on content of specific messages that should be associated 
with specific RP performance events. The position is taken 
here that coaching is highly individualistic and best left 
to instructional personnel* 

When snabled, computer voice generated messagas ai^e not 
transmitted when other communication channel activity is 
sensed, 

Synthesi aed Mission Comjaunicatiqns . A practical and demon-^ 
strated use for" computer -generated voice messages is in 
the delivery of routine, predictable mission comnuniaations. 
This is particularly true when time is of the essence in 
delivering the message, such as during a ground controlled 
approach (GCA) . The capability need not be limited to 
time critical messages , however . The ISS will incorporate 
computer speech generation capabilities for mission-related 
controllers identif iea^-^faelow. the controller models and 
voice generation being selectible from the ISS console. 

Departure controller 

Vectoring RP within warning areas 

enroute controllers 

Approach controller 

GCA controller 

Missed approach controller 

- Carrier air traffic controller center 

CCA controller 
LSO controller 
Bolter control 
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Voice generation capability also has potential for emula- 
tion of tactical communications. Appiications include 
direction of air intercepts and direction of ground attacks 
involving mapping radar. In each case, controller models 
and computer generated voice messages are used to emulate 
a missing crewmember. A full support ISS incorporates 
missing crewmember simulation for cases where adequate 
crewmember models are practical, specific ISS applica- 
tion decisions are required for more precise definition 
of required capabilities in this domain. 

Instructional Intervent inn , A primary theme through the 
IB B conceptualiza tion is o ne of flexibility. A signifr- 
cant aspect of system flexibility is avoiding irrevers- 
ible instructional decision making. One facet of such 
an avoidance is to incorporate capabilities allowing 
for instructional intervention during the course of a 
simulator training session. It can be argued, and wisely, 
that allowing too much flexibility may work counter. to 
standardization of instruction. It also can be argued 
that system flexibility is required to achieve user accep- 
tance. Additionally, instructional intervention flexi- 
bility also is viewed as essential for obtaining feedback 
for use in the design of future ISS-like systems. The 
following paragraphs briefly summarize additional system 
characteristics that are incorporated to enhance the 
flsKibility of ISS. 

Any iSS-supported training session can be terminated at 
any point in time. Neither the student nor the instructor 
is committed to consuming valuable simulator time simply 
to satisfy a computer-resident plan. 

Any ISS-supported session can be stopped temporarily 
through operation of a freeze function. This capability 
is required to provide for uninterrupted instructor- 
student didactic communication. 

Within the bounds previously described, instructional 
users can change from one ISS mode of operation to others, 
although doing so can involve session replanning. 

A reset capability also provides ISS users with the option 
of establishing simulation parameters at the entry condi.- 
tions of designated flight or tactical modules during all 
but NATOPS or other similar check missions. This enables, 
for example, skipping part of a CANNED exercise as well 
as resetting to a completed module for repeated trials. 
Similarly, on-line instructional intervention is allowed 
for inserting emergencies not initially planned. 
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o Instructional User Aids^ Two types of user aids will be 
incbrporated' into IBS to enhance using the systeiTi to 
its full capability to support instructional tasks* One 
type o£ aid is alerting messages and the second type is 
a set of on-line procedural aids designed to provide 
ready access to decision and procedural requirements for 
efficiently operating an IBS. 

The first category of aids when enabled by the instructor 
will present alerting messages involving missiori centered 
training events. In addition to the student prompting 
messages described previously, the ISS can advise the 
instructor the folloving typical information t 

- Next schedulad task module 



Low fuel 



Exceed flight envelope 
Scheduled training time eKhausted 
■ ' - Occurrence of failure 

The second category of aids can be accessed by the instruc 
tor (or TD) at any t line to provide information on ISS 
operation. This capability is intended to compleinent for^ 
mal IP and TD training in ISS usage by minimizing the 
need for these users to rely upon long term memory for 
detiled decision sequences or operating procedures. 
Specific aids should be tailored to a finalized ISS design 
The follwing catagories of aids represent the typas that 
are intendeds 

How to select system operating modes 

How to plan a session using each mode 

How to acceBS student history information 

How to modify a session plan during a 
session 

How to access performance diagnostic 
information 

POST-SESSION SUPPOOT. ISS post-^session support capa- 
bilities fairVithin two categories s immediate post--eessiOn and 
instructional management (after many sessions) support. 
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Debriefing Aids. A three-part debriefing format will be 
provided , Debriefing information will be displayed at 
the ISS console^ hardcopy can be made* 

The first part consists of a graphic presentation of the 
student's flight path history in relation to flight 
module boundaries for airways, carrier operations, 
approaches and final approaches. Where the student has 
performed the same flight modules more than once, all 
flight path historieB are superimposed on the same pro- 
file. Separate graphic output s are presented for each 
tactical engagement" Aggressor and defender profiles 
are displayed* 

The second part is a two-'column, chronological ly-^sequenced 
list of ; 

- Modules performed (objectives met) within established 
performance criteria, along with scores achieved. 

Modules attempted but not performed within criterion 
limits and scores achieved, along with diagnostic sum-- 
mary information (e.g., too slow, below minimum alti-- 
tude, maximum allowable stimulus recognition time 
eKceeded, procedural sequence error, coranunication^ 
missed) . The intent is to provide sufficient detail 
to allow definition and diagnosis of the performance 
problem without overly complicating the output or 
saturating the student or instructor with levels of 
detail that they will have little time or inclination 
to use* 

For the third part, summary scores also are output for 
selected performance categories that correspond with 
(although^ may not correlate perfectly with) performance 
categories on Navy grading forms. The intent is to 
provide a capability that will encourage instructors to 
continue using performance and proficiency measurement 
system capabiiities and debriefing support capabilities 
by providing them with information that will be useful 
to tham in completing required grade sheets. Development 
work is required to derive scoring algorithms that pro-- 
duce summary scores that correlate sufficiently with ^ 
corresponding in.structor-generated grades to this out- 
put so that it is perceived as useful and worthwhile. 
For anF-»14A0FT ISS design, the following performance 
categories should apply. 

Interior cockpit inspection procedures 
Prestart procedures 
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- Engine start procedures 

- Post start procedures 

- Takeoff procedures 

- prelanding/descent procedures 
^ Post landing procadures 

- Failure of stimulus recognitions An overall 
SQore derived from the response froin insertion of 
the failure until the first valid (rneasurable) 
procedural response was observed (aggregated over 
all tailures) , 

- Procedural responses to failures i An overall score 
derived with reference to meeting/not meeting per-- 
fomance criteria associated v?ith individual 
procedures * 

- Aircraft performance understandings An overall 
score derived from eKceeding/not exceeding air- 
craft performance limits for both normal system 
operation and degraded system operation, 

- Aircraft control sensitivity^ An overall Beore de- 
rived from eKceeding/not ejcceeding flight profile 
criteria , 

- Overall GCA performance score 

- Overall CCA performance score 

- Overall AWCLS performance score 

- Overall mission score: An aggregate of the 
above scores* 

Debriefing support may merit eKpansion to incorporate 
output from adaptive logic generation of the next mission* 
This vrould cue the student on what to anticipate and 
prepare for. It would also allow the instructor additional 
time to decide and record whether he would recommend (to 
another instructor) going along with the plan for the 
next session* 

Ii^stractional Management Support. A full support ISS 
m i r pimmr^U^^WP ^ ma naya i tient aupport. One is a 
fluramary of 7.SS utilisation and effectiveness and the 
other is student scheduling. 



- h fixed format ISS utilization report will ideritifyr 
for the period covered, hours of host simulator acti- 
vation, hours of ISS activation, and a summary of ISS 
modes of operation support features used. 

- A second fixed format report will sumitiarize student 
performance at a class level. The report addresses 
proficiency levels achieved by the class for cate- 
gories of modules (flight, emergency, normal proce*~ 
dures, and tactical). It also .summarizes training 
reaources (simulator hours, instructor hours and TO 
hours) required by each class , 

The second type of management support is computer based 
student scheduling, ISS data files make accessible sii^ulator 
training status information for students who are legitimate 
system users. This information, in combination with other 
scheduling information, makes feasible the use of ISS computers 
for scheduling subsequent simulator sessions for students , The 
role of^ ISS in this regard, however, requires further analysis* 
The Navy's Versatile Training System (VTS) is a computer hased 
training management system. The question to be resolved is 
whether VTS fills simulator training sdheduling needs, 

A summary of the proposed ISS functional capabilities and 
modes is shown as a flow diagram in Figure 5* 



54 



Cirriculuiti 




w 

0 

a 
n 

I 

a 
I 

o 



Figure 6. Sdiiiary of ISS Functional capabilities and Modes 
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SECTION V 

ORIENTATION TO OPERATING WITH AN INSTRUCTIONAL 

SUPPORT SYSTEM 



THR ADn--DN COWCKPT 

The organizational concept of an operational flight trainer 
or simulator has generally been to: 

o locate the pilot and/or crew in a simulated cockpit; 

at a console through which the operation is controlled. 

With the advent of advanced training and electronic tech-^ 
nology, it became practical to enhance existing cockpit/console 
concept by "strapping on" an instructor's support^ system which 
in turn will automate many of the existing console operation 
functions. Thus^ the simulator can become a more powerful train^ 
ing tool by using the IP's axperience^ time and skill more 
effectively with his student. 

The "strap on" device will talk to the flight simulator ^ 
computer and displays selected data in return. In fact, it is a 
separate computing system through which the training curriculum 
is controlled* 

The ISS equipment relationship to a current P14A OFT is shown 
in Figure 7. 

OPERATIONAL FEATURES 

By requiring that the ISS computer be readily programmable, 
the device becomes an adaptive ISS attaclunent that can be utilized 
with any type of digital flight simulator or trainer to provide 
the follov/ing benefits and features: 

o Standardises training through curriculum control; 
o Measures performance objectively; 

o Adaptively schedules the curriculum aommensurate with the 
student* s needs; 

o Advances the student by eliminating unnecessary repetition; 

o Aids instructional management through computer stored 
historical files* 

The power and mariner in which the adaptive ISS attachment 
can perform its task is only limited by capability of the training 
management, training analysis and software programmer. In the 
present training environment, the capability of the F14A OFT ISS 
will be limited to the following syllabus i 
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Figure 1. OFT Training Area with ISS Equipment 
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o Normal/emergency procedures 
o Approaches/departuures 
o Carrier operations 
o Instrument rnaneuvera 
o Airways Navigation 
But will provide support functions for: 
o Mission briefing/debriefing 
o Exercise initi ali zat ion 
o Failure insert ion/removal 
o Coaching, cueing, performance feadbacK 
o Mission comrnunications - NFO, ATC, GCA 
o Performance evaluation and record keeping 
o Training problern coatrol 
o Remedial training requirements 

As shown in Figure 7, the ISS console consists of two CRT 
displays which can be used as: 

o a data request device see Figure 8; 

o a data entry device - see Figure 9; 

o a data display device - see Figure 10; 



o 



a graphic display device - see Figure 11 



The CRT face can be used as a touch panel to select and 
manipulate data. However, sorne "quick action" controls will be 
provided to freeze/unfreeze the simulator, to print hard copy of 
the displayed CRT data, silence the voice generation, etc. 

In summary, the ISS can substantially expand the operational 
capability of any existing flight simulator by providing flight 
planning, eKercise management and measure parforinarice for the 
pilot under training* 
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•BASIC I^FOR^/lTlOfj DIRECTORf- 
IMCTIOIilL SUPPORT mm (ISS) F'U 

*T0 lim iOUT Mi OF THE FOLLQWIi PLEASE m YOUR SELECTION 

ELECT 1 ' SEVERAL ASSISTMCE 

SELECT^ . GEM OESCRIPTIOH 
W 

SELECT - SySTEIi CAPilLITIES 

jSE^ ■ PRECAiED DEMOfJSTRATIOfIS 

■ SYSTEM OSAGE 
^LE^ ' TO LOG 0^ 

Figuri 8. Basic Inforitiition Silsction Display 



PARAMETER SELECTION 



POSITION 



RADIAL 
DM£ 
SPEED 

ENVIRONHENT 

cvA mm 

. WIND (over desk) 

SEA STATE 

CEILING 
CONFIGURATION 

FLAPS 

GEAR 

FUEL 

WING 





Shows value selected _ 
(ISS inserts on mM. 
EXECUTE) 



HELP 



Instructor Setup 
TOUCH Desired Value 



leo 



18 



300 



30O 
15 
355 
25 
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130 




2 


3 


250 
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500l 
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130 



350: 



1000 



^000 
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Figure 9. Paramater Selection Display 



Abbreviated Check List 



Responses 





Engine 


Start 






Time 


Event 


1. 


Crank left engine mornentarn)' observe 




(M-SS) 






aux brake pressure gauge 


increase . , . L 


A. 




ENG, CRANK - LEFT 




Start right engine , . . 




□ 


B. 


0-05 


AUX . BRANKE PRESS >50 




a, ENG CRANK switch-OFF 


1 * « « ■ > ^ 


n 


C. 


0-06 


ENG . CRANK - OFF 




(45 to 481 RP 


M) 






O-Uo 


ENG. CRANK - RIGHT 




b. GEN CAUTION light-OUT 






U i U 






c, FUEL PRESS lights^OUT 


' ' n 


F 


0-11 


RIGHT RPM >22l 


1 




> # ■ i 4 » 


J 


G 


0-12 


RIGHT THROTTI F - rni F 




H^d transfer puin 


p fU to 


comb ' ' ' ' • n 


H. 


0-16 


RIGHT TIT >500° 


4. 


Start left enoln 




( — 1 


L 


0-17 


NOZILF - 5 




a. ENG CRANK swItch-OFF > 


n 


J. 


0-18 


RIGHT RPM >55l 




b. GEN CAUTION light-OUT 


* 9 f f * * * 




K. 


0-20 


ENGINE CRANK - OFF 




c. FUEL PRESS lights^OUT 










5. 


Left 


Right 


Nominal 










RPM 0 


57 


63 to 74 










TIT 0 


650 


500 to 600 


(s 


elect] 


MENU 




F/F 0 


950 


900 to UlOO 










Nozzle 3 


5 


OPEN(S) 









DiagnQStic Alerts 

Time Step Event 
0-10 2 E 
0-18 2 J 



MSG 

Right mdZ 
ENG. CRANK - ON 



Rule 

Throttle - OFF till 221 RPM 
ENG. CRANK - OFF by SS% RPM 



Figure 10, Procedures Monitoring Display 
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Figure 11. Graphic Display Showing a Pinal Approach 
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np^T^AT'TNG WIITH THE ISS 

For the F14A OFT at Miramar, the ISS is intended to provide 
the followirig supDort to the instructor during a typical flight 
training session/ once the HP and IP's names have been entered 
through the ISS touch panels 

a. Review and evcauate the RP ' s progress to date. 

Recormnend training content of the training eKercise to 
be undertaken * 

c. Present a pre»Bession briefing covering the instructional 
objectives to be met and the mission plan to be used as 
the training mediura* 

Provide an interogative for the RP to establish his know- 
ledge on flight control, system and operational know-' 
ledges required to enable him to benefit from the exercise. 

Provide instructional cues to the IP in those areas of 
RP pre--exercise knowledge w&aknesses, 

Cornplete the system initialization by entering data in 
keeping with the Instructor ^s Briefing Guide for the exer^ 
cisa or requested by the IP, and which prograrns thei 

O Carrier site data 

o Ground site data; 

o Aircraft environmental data; 

Perform missing crewmember ro by reading NPO cheGklists 
and monitoring RP responses. 

Set up training problems in keeping with content o' ihrn 
Instructor's Briefing Guide* 

Adjust training problem content in keeping with RP*s 
observed performance • 

Provide coaching , cueing and performance feedback to the 
RP . 

Insert and remove system failures* 
3- Vector the RP within a simulated operational area* 
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Evaluate the RP ' s performance in the areaa °^ system 
catiori procedures. 

Perform the following communications cominensurate with 
the eKercise flight plan. 

KiBsioii comnunicationB 

San Diego departure control 

San Dieqo approach control _ 

Lirport Terminal Information Service (AT.S) 

Beaver (search and rescue) control 

MAS Miramar 

Clearance delivery 

Ground control 

Tower 

Approach control 

GCA controller 

Missed approach controller 
intermediate landing sites 

Local area approach control 

Local area departure control 

Local area missed approach controller 

Local area GCA controller 
LOS AngSas Center (appropriate FAA sector control- 

ers) 

rarrier and Comiiiunications - 4-v^^iiat^ 

Carrier Air Traffic Control Center controller 

Marshall controller ^ i i 

Carrier controlled approach controllei 

Bolter control ^ 
ianding Signal Officer controller 
rnstructional communications 
Cueing 
Coaching 

Perforinance feedback 
Mission instructions 

neMiel the HP ---J-^Jf Sl^Sir^easSrSf t^L. 

his performance, ana asciiwa ^jwo-j-- 

Prescribe remedial next training content. 

Perfarm post-exercise instructional management record 

Keeping . 
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SECTION VI 
SYSTEM DESCRIPTION 



OVERVIEW 

This section describes the proposed system from a technical 
standpoint and is partitioned into discussions oni 

o Maii-^Machine InterJace 

o Hardware 

o Software 

It should be noted that as the ISS is a strap--on device, a 
prerequisite of the systeiti design is that it shall not Inipaet 
the existing hardware and software. Much wrk has been done by 
this study to ensure that this requireinent can be met; but oiily 
time can provide the answer on realizability of the objectiv^e. 

As the first ISS implementation is anticipated for an F14A 
OFT, the aystem design is naturally keyed to Device 2F95 ^hich 
would be the host siinulator* 

mil^^tfiCHlNE INTERFACE 

It was realized early in the study that the design of the 
Man-^Machine Interface (MMl) was a key factor in the operational 
acceptability of ISS* 

prom an organizational asp^'Ct, the MMI had to fulfill three 
primary requirements % 

o It had to provide the IP (or in sorne Instances the TD) 
with uriambiguous procedures such that he could operate 
the ISS for its intended purpose, 

o It had to display to the IP information that allowed him 
to control the progress of the exerdise* 

o It had to provide the IP with data that enabled hini to 
nionltor and assess the performance of the RP* 

Commensurate with current display technology ^ a dual CRT 
display group was chosen as the means to fulfill the MMI see 
Figure 12. The displays are situated to mininiize operator move- 
ment of head and arms and to reduce light reflacted from the dis- 
play surfaces. The vertical placement of the consoles (one above 
the other) requires only slight eye movement to view either display* 
This placeinent also achieves concentration of ISS and eKisting 
OFT equipment (shown in figure 13) to minige the operator's 
physical movement between consoles. 
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The lower display will have an integral touch panel capability 
v/hich is used by the operator to select options listed in "menu" 
form on the lo^er ISS display group consoie. The touch entry 
method allows the operator to maintain eye contact with the desired 
selection and avoids having to divert attention to a keyboard or 
similar device* The CRT display for typical touch panel formats 
are shown in Figures 14 and 15. 

The upper display will be utilized to depict the miesion 
history* Figure 16 shows the display cT a final approach to 
recovery on a carrier deck, 

Il^ISTRUCTOR PROCEDUMl AIDS, A system incarDOratincf 
many capabilities can be very compleK v^ith respect to user controls 
options^ data entry and procedures. The touch'-panel allows quick 
selection, thus making It easy to switch frames of information* 
Furthermore, the display can be updated with new information 
rapidly, and a large disc storage will ensure adequate space to 
store sufficient descriptive text concerning ISS without limiting 
its capabilities. 

These features mean that for the majority of instructor 
questions concerning the usage of the ISS, answers can be im- 
mediately available without having to thumb-^through^' volumes 
of manuals or rely on long term memory from lUT coarses. 

Basic information about the ISS is found in a ''menu" form* 
Each selection can lead to another frame that either further de^- 
fines the desired information, or simply provides the desired 
information itself. This style of interaction is depiated in 
Figures 14 and 15: for example, by touching the ■^'SELECT" target, 
adjacent to "TO LOG ON THE SYSTEM" in Figure 
preaentation changes to the content of Figure 

display requests the instructor (operator) to identify himself 
to ISS. If he is in doubt about the meaning of a seleation, he 
may obtain amplifying data by touching any of the "EXPLAIN" targets 

COWTHOL hm DlSPI^i' OF EKERCISES, As aiscussed pre-^ 
viously, Task Modules (TM) represent a basic segment (objective) 
of a flight training session/ TM's include departure, approach, 
enroute navigation problems, emergencies ^ etc., as discussed in 
Section IV. TM's have a one-to-one correspondence to software 
modules. Each software module includes event sequencing ^ voice 
generation, task set-up, performance measurement, etc. While 
each TM can be executed with a set of standard ^'set'-up" parameters, 
the instructor is given the ability to change these. 

Figure 17 is an exampie of the display technique used to 
change "set-up" parameters. The display appears upon selection c:f 
an ACLS Mode Il-T Final Approach TM in the CAM mode. The display 
summarizes key parameters relative to this type of approach. The 
instructor is presented with the standard values indicated by a 
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^BASIC INFORMATION DIRECTORY- 
INSTRUCTIONAL SUPPORT SYSTEM (ISS) 



TO LEARN ABOUT ANY OF THE FOLLOWING AREAS PLEASE MAKE YOUR SELECTION 




= GENERAL ASSISTANCE 




. GENERAL DESCRIPTION 




SYSTEM CAPABILITIES 




^ PRECANMED DEMONSTRATIOHS 




- SYSTEM USAGE 




- TO LOG ON 




BACK UP 



Figure 14. Basic Informatloii Directory 
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-LOG ON SEQUENCE (INSTRUCTOR/T.D. )- 



*PLEASE IDENTIFY YOUR CLASSIFICATION 




Figure 15. First Display of Log on Sequence 
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PARAMETER SELECT lOfl 



POSITIOm 
RADIAL 

DHE 

SPEED 

e:!Viro::ME';T 



CVA CUS/SPD 
WIND (over desk) 
SEA STATE 
CEILniG 
CONFIGURATION 



FLAPS 

GEAR 

FUEL 




'/yU Shows value selectecL ^ 
1^ (ISS Inserts on ISELECT | 

execute; 



Instructor Setup 
TOyCf! DesirGd Valui? 



320 




340 
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340 






13i3- 







3 

7Tm 



1000 











3000 









HELP 


riLECf 


EiCECUTE 






RESET 



SELECT MENU 



Figuri 17. Parametir Silectiori Display 
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"hashed-box. " For instance, he might select an alternate value 
by touching the box representing 250 Pt. ceiling. Furthermore, his 
decision may include opting for the "current" value indicated 
(5000 lbs) . When he touches the "EKECUTE" box, the "hashed" values 
are entered in the ISS/trainer, and event sequencing begins. 
(Note I the instructor might a imply call up this approach and tout 
"Execute"; in this case, the student would be given a standard 
run. ) 

The great majority of instructor selection and control tasks 
will be implemented with such interactive touch panel display frames. 
However, certain significant controls will be implemented by dedi- 
cated keys placed adjacent to the displays. These controls are 
estima.ted to be less than a dozen and ejcampled byt hardcopy, 
freeze, unf feeze, abort, silence voice, etc. Most display frames 
would be annotated to aid the instructor; in addition, an explan- 
atory frame (HELP, EXPLAIN) would be accessible for further assistance 

PROCEDURES MONITORING. The VF-124 replacement pilot 
(RP) simulator training curriculum places significant time and 
emphasis on learning to perform normal and emergency procedures. 
The instructor, at his console, must pay close attention to repeater 
instruments and annunciators to verify that various procedures 
have been performed correctly. However, some relevant information, 
such as throttle position/ is not displayed at the instructor's 
console. Without knowledge of the throttle position, the instruc- 
tor is unable to verify correct starting procedures. Automated 
procedure monitoring capability will provisfle auxiliary support by de- 
tecting and displaying the student's actions that change relevant 
aircraft states. In addition, it could alert the instructor to 
probable procedure violations. The instructor could then focus 
his attention on other aspects of the mission of standard procedures 
with only occasional reference to a display presenting procedures 
summaries. 

A typical CRT display format for procedures monitoring is 
shown in Figure 18. Display of such data is a significant soft- 
ware design challenge which results from several factors: 

o Standard abbreviated checklists serve largely as memory 
aids. What appears as a checklist item often requires 
many crosschecks, decisions, and actions. 

o There are many ways to do it correctly. There are also 

many ways a procedure can be violated. It is challenging 

to encode software to detect the great majority of likely 

violations and to report the violation in a meaningful way. 

o There are well over a hundred different failure and emer- 
gency procedures for the P-14A. In addition, new emergency 
procedures or alterations to existing procedures occur. A 
challenge exists to encode procedures monitoring software 
at low unit cost and yet provide the required flexibility 
for change. 
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Abbreviated Check list 

Engi ne Star t 

i. Crank left engine momentarily observe 
aux brake pressure gauge increase 



Response? 



i « • » 



I, Start right engine 

a. ENG CRANK switch-OFF . 
(45 to m RPM) 

b. GEil CAUTION llgh^OUT , . 

c. FUEL PRESS lights-OUT . . 



3. Gnd power - DISCONNECT 

Hyd transfer punip fit to CQfiib 



4. 



Start left engine , . . 

a. ENG CRAuK switch-OFF 

b. G£fi CAUTION light-OUT 

c. FUEL PRESS lights-OUT 



5, 



Left Right 



□ 
□ 



Tjrif) 

A. 0-00 
G. 
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Note that the diBolav illustrated in Figure IB has three 
inforrnatlon areas. The "Abbreviated Checklist" area simply rapeats 
the checklist as found in the NATOPS Ttianual, with checK: mmrks 

automatically placed alongside completed items. The "ResponBv 
area shows studant actions as they occur, together with air cr^r^tt 
state changes relevant to the procedure. The ''Diagnostic Alert" 
area shows apparent procedurG violations as detected by the computer 
together with a short description of what was found "wrong" and 
what "rule" was violated- Aside from the software design challenge 
of such a display, an indepth training analysis is required to 
establish diagnostic information with which a representative 
sample of IP's would agree. NonGtheless, a flexible, responsive , 
full support ISS will require substantial analysis and software 
investments. To some eKtent, the investinents will have to be ^ 
continued as training requirements change^ and the ISS is modified 
to keep pace with the changes and to meet revised training require- 
ments , 



KABDWARi: 

It is considered that hardware should be selected to imple- 
mant the ISS in two ataqes as shown in block diagram form by 
Figure 19 • The tv/o--atagG hardware irnplemeritation is compatible 
with tlie "tailored" and '^full support*' tSS objectives expressed by 
this study whereby the system will ^^girow" as the result of on- 
going ISS development. 

The hardware complement would be as follows: 

^^^£lication P cocesBO£. ISS training capability would bo 
implemented Ky ^cTFtw^^ residing in this unit- The unit 
should be selected primarily on the basis of the avail-- 
ability of state^of -^the-art multi^programining operating 
sy steins , 

Trainot Inter^faq^. This interface must provide sufficient 
dTtT^t^?Pthe^lcCs^ "bo determine the instantaneous atatus of 
the trainer, includinq all cockpit instrumentation. In 
addition, tne interface must provide the means whereby 
the insUructor can e:<ercise control (i.e., setup environs- 
mental conditions^ training problems, reset airoraft 
position and insert failures) , 

Instructor's Display Groug. This unit is the critical man- 
machTni^TnTTi^ the instructor it is designed 

to serve. The unit would be composed of two displays. 
One should be a graphic display that portrays the geometry 
and history of the mission. This display would be pro- 
grammed to show departure profiles, warning area overview, 
airways routes, init;ial approach profiles, final approach 
profiles, and narri^^r operations profiles. The second 
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display would be equipped to ha^^e a touch entry capability 
that can be^ programiTied to allow simple control over the 
ISS modes and features* Available control options would 
be apparent from the display content. 

DisG Drive . This unit would provide storage for the ISS , 
Stored on the disc would be a complete set of program 
development software as well as applications programs. 
In addition / a complete log of ISS training activity 
should be maintained in files on this disc. These files 
would allow the instructor to review student performance^ 
and/ would provide the training analyst with the basis for 
objectively recommending improvements of the training 
seqiience, modifications of performance norms and improve^ 
ments in design. 

Voice Synthesizer , The ISS would autom4 a routine, stan-- 
dardi zed / predictable voice transmissiori^. For instance, 
ISS should provide GCA voice messages as the student flies 
a simulated approach, 

Printer/Plotter, This unit would respond to cormnands o 
the IP to the ISS to prxnt either alphanumeric or graphs. ^ 
information. The instructor should be able to obtain a 
hardcopy image of either of the displays. Using this 
device items / the ISS would print such information as 
inission briefing and performance summary data. The unit 
also would allov/ users of the system to obtain program 
listings, statistical reports and graphs. 

Maintenan ce Terminal , A small keyboard/printer would be 
incorporated" for maintenance purposes. Such a unit is 
necessary to run diagnostic rc. ..ines for the CPU and its 
perj.pheral devices. This unit also would have the means 
of modifying the ISS's software. 

Magnetic Tape U nit . This unit would serve tv/o functions: 
file p"reservatTon and data transportation. It is essen^ 
tial that an ISS data base be preserved. The system 
data base must be restorable from recent magnetic tape 
recordings should a loss of disc data occur* In addition/ 
it is considered prudent that performance data collected 
on the ISS be subjected to analysis. Magnetic tape pro-- 
vides a proven means whereby data files may be trans- 
ported in a secure manner to other facilities for analysis. 

Remote Display Group, This unit is a stage II requirement 
and would" be identical to the instructor's ISS station. 
Instructors and students could use the station to conduct 
planning, briefing, and debriefing. The station would 
be able to be operated simultaneously with a training 
mission, and it should be located in a briefing room 
close to the trainer. 
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Di.VICC: 2F95 I.-rTEPJ-'ACi; 

ma accords ^wv; .vn, . ; nr. ..n nnji u ion in Device 

nr',-. ar- or primary -w^-etr: . i ibi 1 i t y o!= a-i IBS for the 

F=^^d^ OFT. Two intei-acv- . ;- - i '^'u.■,;: must mocot the 

objective or non-int.:r . v..,-..; u:o u/'l ■ . internal data 

transf ars . 

General deacriutLona t.r th.^ two i:cquirud interfaces are 

s!i-.A./n in Figure 20 nri.. '-re , c r Lb.;;d .ow. 

^ DirRCt Memorv Acccsy (DMA. ,:3 recommended co access the 
OPT's Siqna Five -ore memorv i ^ memory port A. Thr^ will allow 
the r.K^raetion oE certain iniural vaiiies prior to the exercise. 
Less\h.n'50 memory aooo..e3 u . rato of 1 per 4 to 10 mrlliseconds 
win ho required. ^During che excrciac, it may be desirable to 
road a^fevrdesa than 10) memory locations for a total of 200 ac- 
cesses per second to ..c ruiro d...:, a-ail.ble only m the Sigma Five 
memory . 

An mtorfacu conn... t.d be.wowr, the MultipleKed I/O Processor 
(MIOP) and Lhe ;.>ovice Controller.^ (DCs) in the OFT cabinet (unit 
6A Us planned. Thi. .n^.e,..co is c.ll.d ^ D^^a Acquisition and 
control Systom ^DACS , , 1 ■ .nuicipated tnat it could be similai 
in concept to DACS : ed m ..;her trainer installations. 

Tho DACS allown .ny aar. flowir .rer this MIOP-DC link to 
be acquired and planed vi. DMA (dat nel) into the mernor; of 

the lis CPU. i;urtnc.r-,o:e, :ca:i;ow :ata destined for i 

MIOP from these d.vi.e .on-:ro 1 : .r s ■ intercepted ana no. 

fled. This capal^i-t. ^llc:^ Hie 13. . to insert mstruc . 
which would nomally be. ::on;inq fron -.e instructor's consol.-- 

The DACa should require no Dy/. access to the Sigma Five core 

Tr ' - b'. b :c havo no adverse effects upon the 

opSaiion of" th. ;«.by .h. operation of th. input d.- 

vice controllers. 

The P^dS WM: ,.r,...:.-: vp--,: i 'natcly 100 different words (less 
h;:;.) -t- wH: . mo; /or modify) about 25 input words 
fi^i iJLsf:^lHaee%cti.:ni ■ t. repeated. on ^^^/^^^ 
of which there are 5 tw 20 pu . ;u:eo-d depending on the device. 

The DMA Contxol ■ r.. d^.:^ InL. and POwer supplies can be 

' i , 1 . - -p- he.i i-'j I he rear o£ memory cabinet 

mounted on a sixioial p-'--^- i . . -.e-.> j i K-Ki^-i +-t,o ^vternal 

(unit 6A6) Ai: enuiomout can be concealed behind the external 
ioSr tJ the cabinet. >he p.nel uhould .wmg out for maintenance. 

Three card runnir:; fro.: idvn MIOP in unit 6A5 to the device 
controllers can 1.0 . • d and Intercepted by the DACS located on 
this panel. 



ERIC 



Access to mf^raory port A in unit 6A6 also would have to be 
established for the DMA interface. 

Power can be obtained^ up to 10 amperes from the 60Hz, 120V 
singles-phase outlots behind the counter-weight at the bottom of 
unit 6A6. 

Cables to the ISS CPU would be routed under the floor. 
There will probably be two cables with a total of less than 100 
conductors . 

The interfaces must function in a manner requiring no changes 
of the software of the Sigma Five computer. The interfaces would 
be xniCwive fox^ any one or more of the following conditions^ 

Power^off in ISS CPU 

o Following "power up'- or reset of tho ISS CPU 

o Whenever a special switch is in the "bypass" position 

o Following a "bypass" command by the ISS CPU 

In other words ^ the interfaces should function only when ISS 
power J. a on/ a manual switch is in the operational position, and 
the appropriate ISS CPU commands are in effect* When these con-^ 
dit:ions do not exist/ Device 2F95 would operate without knowleac/e 
or benefit of the ISS* 

By means of bypass c^^vds anci/or other disconnect methods/ 
the interfaces would be easily and completely disconnected fro^a 
the trainer. 

Build-in test equipment should be designed into the inter- 
faces to facilitate off-line maintenance* 

Other configurations of DMA/DACS interfaces are feasible 
and practical, for inst^u^-m , a single box can be placed in the 
link between the MIOP and the Sigma Five core memory. This would 
allow the ISS CPU to r-ad or write into the Sigma Five core 
memory and, furthermore/ would allov/ acquisition and/or modifi- 
cation of selected data flowing to/frc;m the MIOP* However/ the 
final interface configuration should be a contract review item 
with the system implementation contractor based on a requirement 
that the ISS shall not interfere with the operation of Device 2F95 
and that the ISS shall fulfill its intended performance. This 
would give the contractor freedom of choice in optimizing the 
interface , 

SOE^TWARK DKSCRIPTION 

The goal of the design of the ISS is to emphasize modular 
software* A modular design allowg low'-cost eKpansion of sy&tem 
capabilities* All applications-level programs should be done using 
an efficient/ easy to understand/ higher-border/ latest technology 
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programming language. Inter=-module cormnunicat ion and timing 
control will depend largely on the operating system selected. 
The ability to provide affective and easy to understand inter ^ 
module communication should be a primary factor in operating 
system selection. 



As can be seen by the illustrated hierarchy diagram in 
Figure 21. the IS3 is conceived of as a large collection o£ 
program units. The ISS should be dasigned to be a self-supporting 
system; that is, using on-line program development to provide 
the rr.3ans for appJ icatio" nv-og^^^rr.s to be modified at the source 
levn' . Th^^ Operating ^ system recommended by the equip- 

me- 

u : Li 1 ^ 



supplier should bt. 



..i!ed for ISS applies: tions and sched-- 
This would virtuti^^y eliminate i;he cost of developing 
real-time executive and I/O control software* 



Note that apjDlications software will represent the largest 
category of development labor and cost* 

DATA BASE DESCRIPTION 

The following paragraphs describe identified elements of the 
ISS data and outline their requirements. 



Task Modu^ 



Performance Recor 



The basic data entity 
the Task Module (TM) performance 



within the file system lb 
measurement record. Each record should contain several 
variables as measured hj the TM performance measurement 
logic. It mast be possible to access these data and any 
related diagnostic and amplifying information relating 
to the student's prior performance of the specific TM. 



EKercise File 



This file will be associated with a partic- 
u 1 a r instructor and student. From this file it should 
UB possible to identify which TM*s were used during a 
specific ^3ir^ulat:or exercise v/ith the relevant amplifying 
data including^ the ISS mode(s) of operation used, 
instructor overr , environmental factors^ concurrent 
amerqcncies , etc 



TiM His to ry 



It. ' . be possible to determine within the 

file structure a. ..ecutions of a TM. All amplifying 
data relevant to the eKecuting of the TM will likewise 
be accessible/ including: student, stiident classification, 
instructor, as well as mode of operation, instructQr 
overrides, environmental factors and the presence or 
absence of concurrent failure "md/or emexgencies. 



J L id ent History - 
bT5"'to "determine: 
lator exercises 
performed and tw 



For a given student j,t .lould be possi^ 
nrior level of expex'^ic ..ce ^ all simu^ 
:}L L ormed and al 1 mission 
,vhat criterion levels. 



.ements (TM's) 
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Instructor History . The system, in part, should de- 
signed to determine effectives training technigueG irom 
the variour instructors. Thus, given an instructor it 
should be posrlbie to determine the specifia exeruist^- 
he has supervised and^ in turn^ the modes t^y ^^^hich they 
were executed along with a list of modifications the 
instructor performed . 

Normative Datn Files , As a history of the usage of the 
system builcli^r normative data should be computed for 
var ious'-pe r r urmance parameters. These data could then be 
used to re, acp i:he initial "best^guesses " used for 
scoring* Moi tive data files should be organized by 
the student's time in terms of training, TM^ and per- 
formance measure. 

RP Proficienc y Files . In the OFT training program, various 
criteria for student attainment can be defined* These 
files should list the number and categories of TMs flown 
to criterion level • These files should be displayable 
to the instructor with student achievements "checked off," 
This provides the IP with an aid for effective and effi-- 
cient planning and budgeting of his time on the simulator. 

DATA RETRIEVAL Pd. > ANALYSIS 

A library of programs allowing retrieval of data should be 
a part of the ISS/ These pre grams would allow a training analyst 
to ■ 

o determine normative values of performance parameters; 

o refine scoring algorithms based on statistical data; and 

o correlate instructor technique with student performance 
data . 

The objective oh these analyses is to refine and improve 
the ISS, 

Usage of these programs siiould allow a training analyst to 
print out the data on all eKecutions of a given TM. The printed 
data should include the date, instructor's name, the student's 
name, training level, relevant anvironmental values, and the 
presence of failures, as well as values of performance measure- 
ments. A more sophisticated use could allow a training analys^t 
to reject certain occurrences and to determine statistical charac-- 
teristics of specified variables for the remainder. 
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DATA FtLH :iOUSKKEEPIi;G 

A lor.H ot filDfl din.! ■ o(\'.r..\"\\<-}\\t •,.-ror, [.-rogramnu nn o,rror 
fjr iiurr,..! error could aoi: i cui; .;,y j '.i'.!; si i-.iize the cjoals ot '.alninq 
an lur-outatod instructional .sMDpcrt ui'vLcw. Means must t)u ..irovidt-jd 

r. D p r o K e f \' s t h e cj r o w 1 n g d a t: a b a s . 

A nliiu thn:. reriiros ' iily racordinn oi chnngGd or now files 
plus waGkly cherV po j'nt mg oi che ftntire data base is recomiiiended , 
FtiG aud\t nrograins lihould b'-> pro'/uied o the SKtont practical 
that v/ili detect ^2rrors in tiv: files. The use ot a standard 
magnetic tape Linlt is reconimcn n.'d £o'r this purpose in anticipation 
of transDorninq the XSS's files to a remote facility for analysis. 
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SECTION VII 
IMPLEMENTATION 



OVERVIEVI 

It is considered that the Device 2F95 ISS can be implemented 
m three stages as discussed herein. It is not intended" to imply 
that other strategies would be inappropriate. The proposed plan 
does reflect the best judgement of the study teain in this regard 
at the time the report was written* 

The proposed strategy provides for user feedback at a 
reasonably early time, while providing a reasonable development 
and evaluation schedule for the more compleK of the aoftware 
modules. 

Stage I is viewed au an 18 month effort that would focus on 
an early demonstration of the fundamental features of the ISS, 
The ISS 2F9 5 interface would have to be developed dinring this 
stage to provide a means for tne field demonstration. Preliminary 
instructor software to provide diagnQstic perf orrtiance feedback 
on emergenay and normal procedures also falls in this category. 
The capability for the automated support of departure and approach 
training task modules should be inciuded to allow user feedback 
on the automation of the flight control and navigation modules. 
A limited version of the CM mode should be implemented. The 
basic system would bi- delivered at the close of Stage I. 



Stage II also is conceived as an 18 month effort. During 
this stage; a second (remote) instructor contr Dl--display con^ 
sole would be added for mission planring^ briefing and debrief inc 
instruction* Additional software delrveries would implement the^ 
remaining ISS operating modes, including the carrier operations, 
the airways navigation and additional procedural TM's, lUT 
training materials should be developed and validated durinq 
Stage II . 

Stage III xb a 12 month effort to refine the ISS modes, 
automated support features and operations, Th^ logic for adaptive 
trainang would be developed and implemented, Coinputerized voice 
recognition of Rp radio transmissions should be incorporated into 
the system* A formal evaluation of the ISS shoii^ i occur during 
the closing months of Stage III, 

Figure 2 2 graphically clep:,cts tne recommended candidate 
program stages. 

STAGi: I 

Tr a priiaary S ;-age I requirement is to focus on developing, 
demonat-at; rg ^na t^^valuating the acceptability of the features 
and ^ . j " ti rife; o\ rhe ISS as it presently is coriceived* From 
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an instructor-user's point of view, thiH may be sumnar". by two 
questions % 

o Is the ISS inan--machine interface easy to use, 
ana does it provide the user with relevant 
inforrnation and the capability for control? 

o Do the ISS's features and capabilities offer 
meaningful and useful aids that assist IPs in 
performing their primary function. instructing? 

Early answers to these questions are needed to provide 
guidance for subsequent design and implementation decisions. 
Positive answers will provide the confidence that the basic 
design is good. Negative feedback should be useful for re^ 
directing the development activitiea for their efficient use. 

The design recoOTnended for the man--machine interface must 
be evaluated early. This includes the planr4ed graphics display, 
the use of a touch panel, the IP's procedural aids, and all the 
problem control and monitoring display formats* This is felt 
to be necessary because of the reed for instructor acceptance 
early in the implementation program. A primary ingredient in 
the instructors' acceptance of the system v/ill be their acceptance 
of the methods, media and procedures for using the ISS. 

Stage I also will serve as a test period for the software 
as well as for the instructional capabilities. A primary example 
involves the capabilities to automatically monitor and inform 
the IP of the pilot *s performance of normal and emergency cockpit 
procedures. As this is a new and andeveloped automated support 
syatem, the Stage I JSS should incorporate the software for 
procedures monitoring, including the diagnostics related to 
improper execution by the RP . Expanded criteria for the auto-- 
matic insertion of failures and their removal also should be 
developed for this ^caLqe. 

In addition to the monitoring of procedures, the Stage I 
□ystem also should incorporate the ability to monitor the basic 
flight profxle, the performance measurement and the scoring. 
This will enable their refinement later. Several departure and 
approach task modules should be included as these also provide 
an instructional context for meaningful use of synthetic voice 
generation. The incorporation of a GCA and ACLS Mode ll-^T 
task module should ba a stated objective, 

STAG^ II 

Stage II allows feedback to affect the system's design and 
commence when the remaining ISS automated features, short of 
adaptive training, are introduced. Automatic insertion, removal, 
and monitoring capabilities for the remaining normal and emergency 
procedures would be implemented in this stage. The flight control 
and navigation context would be expanded to incorpot^ate additional 
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departures, warning i^r>-^.i opcirations, airways navj 't:' tion , operations 
at intermediate landing sites, carrier operations, approaches and 
final apDroacnes. Thus, the: majority of all of the TMs would be 
implomenttsd in Stage II. Darn filep for retaininc) student's 
performance measures and information on their proficiency would 
be implc>mented also. The second (remote) IP control-display 
console would be del iverc- ='t , together with mission planning, 
briefing and debriefing c,::ipabil it ies . 

In is c-onsidereu tnat a civilian xnstructionai specialist, 
tiither Navy or contrantor, be resident at the installation through- 
out Stage II. Such an individual v/ould fill several valuable 
roles. "One role v/ould be to provide on the job training f or _ the 
initi.'il cadre of IPs to use *^he nearly completed iSS. In doing^ 
&,o, he could accumulate valuable knowledge on the acceptance and 
utility of various system capabilities, features and procedures. 
Additionally, he could use experience gained by working with the 
cadrt=^ of IPs to develop objec --.ivos and content for the lUT pro- 
griim. Finally, it is anticipated that he could coordinate the 
analysis of thn arowing b je of performance measureJnent and 
instructor usage "data so thcit the proper adaptive training niodes 
and logics can be astablishr-d . 



sracjo tir would focus on the development of adaptive train- 
inci logics for betv/een session problem adaptatiion, together with 
rjreliminarv tests of the logics. The conclusJon of Stage III 
should concontratr on a s-'stem operability and training effective- 
nosH evaluation of the ISS and the lUT program to provide feed- 
back for future instructional support system development. 

hard^tarf; stac"t:;g co:isinr;RA'T'inr]s 

Stag-f I hardwaro ohould incorporate the rn.iin CPU and disk 
meiriory, wnicn are sized for a multi-programnii.ng program develop- 
ment and real- time operating system. Howevar , Stage I should _ 
bo designed to minimize costs until the fundamentals of the design 
are proven by demonstration and acceptance by_the IPs achieved. 
Some%xppnditure for hardware could be delayed until Stage II 
for some reduction of efficiency of the software development. 
SDccif ically, a lOM byte disk drive could be substituted for 
the reoomniended 96M byte drive and magnetic tape unit. The 
larqer disk, however, is still required in Stage II to provide 
f=-he capacity for the anticipated performance measurement data. 



CoKfiguring both the graphic and menu displays with the 
same CRTs offers several long range benefits. First, the system 
would have redundancy; second, the graphic capabilities could _ 
prove usarul for future display design. However, a less eKpensive 
alpha=numeric display that providos the necessary symbology tor 
touch pane] interacticn for menu manipulation could be selectea 
and lead to deletion of the requirement for a maintenance terminal. 
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Stage II also adds a second display grro^P and a second CPU 
for display processiiig. The second display grroiip^ i/^hich shoald 
be identical to the instructor's display^ wo^ld be located in a 
briefing room near the simulator. Its purpose is to enhance the 
mission planning, briefing, and deteieCiny fiincfcions of the ISS. 
h dedicated display processor is also addad at this stage to 
rernove the load of display processing Croiti the applications 
processor. This would allow expanded traLniiig applications. 
Depending on the aitioiint of I/O transfers Siam the disk; it may 
also be necessary to add a cartridge disk unit to the display 
processor during this stage. 
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SECTION VI IT 
LIFE C'/CLE SUPPORT C0NSXD^;R/\TtOfrs 



■iMi-JV EimMCE CONS inn ratthms 

The ISS should be configuresd mainly ftoiti comnercial equip- 
n(it\t, and, therefore, each equipment vendot should have ari effec- 
tive field maintenance organization in tl j iristallatlon site area, 
2ach hardware unit also should have a significant llfetiiTie. All 
Df £-the-shelf harclware used should incfocpotste diagnostic programs 
ind iiecassary equipiiient to isolate failures to all easily replace- 
iblc module or unit . 

As the Stage I systeni is viev^ed as a ptototvpe device, should 
anexpected technical difficulties arise or shoiAia acceptance be 
in£r\rorable, it will make littlei sense to puraae expansion and re- 
Einer.ent of the ISS. Because of this rjosslbility , it is recommended 
that dev-clopmQnc of raaintenance do-^mentation and provisioning parts 
aocuinents be deferred. 

STAFPILIG COTWTnnR&T'TnM.q 

A need is anticipated for three people in additiori to those 
lorrtially required to operate and maintain Device 2P95. Each new 
Dosition is diaGussed below. 



Technician support will be required fot preventive maintenance 
trouble shooting, and monitoring of eytpendables . This should re- 
Tuire approximately only four hours per week. A reasonable plan 
^ould ^^ipoear to be to provide TDs witn insttuctlons sufficient to 
=>nable them to adcdress thuso requirements. Duping Stages 1 and l^, 
it woulcl appear moat practical that maintenanca be provided by the 
iSS devalopment contractor, 

/\ data control o^irson also will bm re^uir^d to control the 
ISS software validity checks. Tt is anticipated that this should 
reqiiirp no more tiian onc-hal£ bour daily aiid t%o hours at the end 
of the week. This role also could be filled by a TD. 

An important rrasearch role iJi alscJ anticipated. This should 
be filled by a full-time, civilian instructlOJial specialist ^Jtb a 
background in instruction research. Tbe succeas of the ISS ot the 
tYv^ discussed in this report could depend on this individual. The 
instructional specialist will have to perfotm many critical tasKs. 
During initial system operation, ho will have to PfO^^J^/P ^"f J° 
on-the-job training. Frnm this experience, he could make detaaled 
inouts to the lUT course providing bocb objectaves and content . _ He 

will be the contractor's source og aset aQceptande and des:Lgn 
^nPormation. He will also bn required to direct or Pf^fo^f,|f\^ 
analvsGS to aid the refining of performance scoring algorithms, as 
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well as the de\reloping and refining o£ adaptive training logics. 
Pinally, he shou^d ensure that the task modules are refined or 
daveloped so that the ISS is kept curirent with changes to the RP 
syllabus. 
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SP'.CTinM IK 



rNTFiODUCTION 

during mission conduct. Ma jot rtax 
(tnodLilea) are 4raacribed. 

•^,1 cparwiees othef than mission 
While ISS performs many vital seivices ^^'^^^ efficient 
conduct, these other lunations a., designed^ syllabus 
and effective t«inin,. Jl^^r^^'l^^^^nning, and mission 
maintenance, instructor draining, mx.si p j^^g^arch operations, 
briefing and debrief mq , ^^^^^r^totlecl to be considerably less_ 
The support eunctions aro anticipated to b^^^^, computational 

^^^^^^"^ ^l.u.,%niy .isaion conduct oper^ 
at ions are described. 

..,ure 23 depict. in£orr.atio. flow t^^^^^^ 
an ISS ilsaion. Tha critical J'J'^^Ld to ths instructor a« 

llllT Sc^'^l«St£?rant".srso1ttSr.-p.oc... (.o.uXe, is .ep.ctea 



as a circle 



MODULE SUIiimR':^ 

. r Tss soft^vare modules. 

Table 1 Ue^cribes- brietl^, ths I-S so - 

lepicted in Figure ?3. 
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Note^ Some data 
lines have been 
b3fc»kw for clarity 
these ara identified 




Figure 23* ISS Data Flow for Mission Conduct 
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TABr,E 1 



MISSION CONDUCT SO^'TWARE MODULE DESCRIPTIONS 



Output 



Traln ar Data Acguisi/- 
tion 

Aircraft dynamics 

Cockpit sv7itches 
controls & indica^ 
tors 

Navigation aids 

Event Detactor 
^ ^Event deTinition 
Tnessagas 

Trainer state \/ar- 
iables 



Perforraance _^'^g§£H£H^ 
ment (P_M) 

EvGnt messaqo 



Scoring 

Measure fii^J 

Norm files 

Roport forinat 
files 



i ^lalfu^t^on^_I213i^^ 
! ^ Event "mesKaQ^^ 



Trainer state 
variables mis-- 
sion history 
log (flebugging) 



Event occur-- 
rence messages 



Measure file 



Communicate lincr 
status and trainer 
action to other ISS 
software elements 



Notify ISS rnodules 
of spGcific Qvents 
of intorest* (e*g.j 
wheels down , alti-^ 
tude 10, OOO) . 
Complox expressions 
must be implsmented . 



Activate performance 
moasurcment coniputa-^ 
tions upon receipt of 
star^ event. ^. Collect 
moasures until stop 
nieasure event. For- 
mat PM data report 
on task completion 



Transform measures to Display page 
scorei^ using criterion p^j^j^^ page 
^.jc normative standards- 



When notified of a Trainer control 

relevant event occur- commands 
ranee / perform detailed 
I/O seqaenca to enter 
or dolcto a malfunction 
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TABLE 1. MISSION CONDUCT SOFTWARE MODULE DESCRIPTIONS 
(Gontirmed) 



Inpigt 



Function 



Out put 



GrQun d Coritroller 

Trainer state var-- 
iables 

Airfield and pro-- 
file files 

Event messages 

Navigation aid 
paranieters 

Pilot phrase re^ 
cognition 

Voice Cominun lea t ions 
Phrase serections 

phrase file 

Speech recognitions 
voice patterns 



Touch Entry 

Touch K-Y 



A/N^^l phanumer ic 

Instructor Request 
message 

Display request 
messages 

Menu/page file 

Alert messages 

Instructor Control 

Instructor request 
meesages 



Emulate the UHP radio 
transmissions of var= 
ious ground control- 
lers (e.g., QCh, CCA, 
Departure) , 



Generate selected 
phrases via a voice 
generator , Conform 
to half--duplex UHF 
protocol * When 
speech understand-' 
ing is added , re-- 
cognize phrases 
spoken by the R.P- 



Decode touch X-Y into 
processing require^ 
ments 



Format alphaniimeric 
(menu) display pages . 
Respond to " secon^ 
dary" instructor 
selections ( e , g . help 
frames) 



Process "primary in- 
structor selections, 
(e.g, sign on, log 
off, mode select ion, 
abort requests) 



Phrase selec- 
tion messages 



Phonemic codes 
to voice gener- 
ator 

Pilot phrase 
recognition 



Ins tractor re- 
quest messages 



Display list 



Initialization 
Task termination 
Mode selection 
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'I'ADLC 1, MISSION CONDUCT 
( continued) 



aOFU'WARE MODULE DESCRIPTIONS 



Input 



Task sequencer 



Task Initializer 

Parameter selection 
ontries 



Function 



Output 



Maintain mission task 
list. Monitor task 
completion and close--^ 
out; activate next me- 
quential task . 



r^resGnt task parame-^ 
ter entry display* 
Command initial 
trainer setup/ as 
a p p r o p r i a t p , Ac t i. - 
^/u te perf oCTTiance 
inoapures , event 
d':j script ion / and 
procedures logic as 
appropriate . 



Task selection 
message 
Mission task 
list 

Task initialiaa- 
tion requtssts 

Parameter entty 
display page 

Trainer setup 
commands in^ 
cockpit 

Problem briefs 
ing via voice 
generator 



Task Setup 



Setup coniniands 



Dec od e setup c om^ 
mand s i n to spec i f i c 
trainer I/O control 
sequences 



Trainer control 
commands 



P r o c edures Moni tor 
Event messages 



Determine conformance 
of pilot .ctions with 
Buecif ied procedures * 
Rapor t re le vent 
events to the instruc- 
tor diBplay. Clas-^ 
Hi fy and report 
apparrent errors , 



Event descrip- 
tors 

Procedures dis^ 
play 

Performance 
measures 



Graphic Displax 
Task seqijence 

Display control 
comiTiands 



Display mission geo^ 
metry. Actual track 
h Lstory xb plotted 
aqainst dnsired pro-- 
file. A split screen 
vnr t ic:i 1 and horizon- 
tal plot to be used 
for final approaches 
to land j ng. 



Graphic dis=" 
play list 

Graphic hard- 
copy snapshots 
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SECTION X 

USER TRAINING 

CnHSIDEnATrONS 

Training of the IPs and TDs will be required to assure that 
the capabilities and features of the ISS are used effectively during 
routine training. The TDs are included inthe training requirement 
for three reasons. 

o Sorne FRS IPs may wish to rely on TDs to operate ISS* 

o TDs will have to operate the ISS during unsupervised "eKtra 
training. " 

o A skilled TD will likely be required to assist Fleet IPs in 
ISS procedures . 

A short course of instruction also is considered necessary to 
introduce Fleet instructors to the manners in which ISS can support 
them in their instruetion and evaluation of students* 

A nuinber of support features on existing training simulators 
are not used at all; others are not used as effectively as they 
could be. This occurs, in part; because IPs and TDs are not aware 
of them^ do not know how to use them^ find the features of marginal 
utility^ or find them difficult to use. The ISS design has attempted 
to minimize these problems through careful organization of the 
systems, through design of the man^machine interface, and the incor'- 
poration of user procedural aids. However, the ISS can be cost-- 
effective and can meaningfully support instruction, only if it is 
used properly. This will require training of its users, 

INITIAL THAINING 

A formal training program will not be needed initially, assuming 
a phased implementation of ISS. This statement is predicated on 
the assumption that the developmental contractor and the on'-site 
training analyst will work closely with a limited cadre of IPs and 
TDs. Thus, instruction of the IPs and TDs could take place on a 
one-to-one basis. EKperience gained from this process should pro-- 
vide information for a course outline, for instructional materials, 
and the instructional methods to be developed. 

PORflAL TRAINIWG 

Ultimately^ a formal program for training of the IP's 
and TD-s in the effective use of the ISS must be provided* A 
logical structure in which to incorporate this training , is the 
lUT training program. The following is suggested as a syllabus 
for the required training module. 
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b 



Effective usa of simulators for Flying training 
Training objectives in their structures and purposes 
o Training quality control and proficiency advancement 
o The instructional support rolo of the ISS 
o Modes of operation of the ISS in relation to its role 
o Instructional support features in relation to modes 
o Operating procedures for the ISS 
o Effective uses of the ISS 



If is reconmended that the module be self -contained with clear 
instructional features. This strategy will provide its easy incor- 
ooration into an existing lUT syllabus, while enabling IPs and TDs 
to repeat the instruction as required. It also is reconmended that 
the formal program incorporate hands-on demonstrations by IPs and 
TDs of their ability to operate the ISS following instruction. 

Furthermore, the svllabus should have a closing segment in which 
instructors experiment with the iSS capabilities. Following an 
evaluation of this " f re^a'■f orm" instruction, the closing segment could 
include details of uny lessons learned and a summary of possible 
mistakes made by the instructors. 
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1^ APPENDIX A 

LISTING OF NORMAL PROCEDUBES MJD FLIGHT MODULES _ 

NORNlAL PROCEDURES MODUiES 

Interior Inflpection Pre-Start 
Engine Start 
Post-Start Checks 
Takeoff Cheoks 

Pre-Laatich Setups (carrier only) 
Pre-Land/Descent Checks 
Landing Checklist Procedures 
Post-Laiiding Checklist Procedures 

TAKEOPF/LAUNCH MODULBS 

Military Power T.O., Miramar 
Zone 2 Afterburner T.O., Miramar 
Zone 5 Afterburner T.O., Miramar 
Aborted T.O. , Mdramar 
Single Engine T.O. , Miramar 
Carrier Launch, Ship 

DEPARrURE MODULES 

Miramar, Seawolf-Seven Departure ^n^-rar 
^ Miramar, Hensha«-rhree Departure to Thermal VORTAC 

Miramar, San Pedro-Five Departure 
Ship, Taetical Departure 

WARNING AREA MODULES 

Whiskey 291 (Seawol f-Seven Departure) 

AIRWAYS MODULES 

India Route 3 3 (George AFB) (Henshaw-Three Departure) 

Thermal VORTAC direct to Needles VORTAC 
Needies VORTAC direct to Hector VORTAC 

Hector VORTAC direct to Premont lAP .mRT-ar 
(Prom George Mi,.aed approach) direct to Los Angeles VORTAC 
Los Ancreles VORTAC direct to Oceanside VORTAC 
Ocean side VORrAC direct to MIRAMAR UHF Radio Beacon 

India Route 3 5 (March AFB) (San Pedro-Five Departure) 

Tinny Transition direct to Los Angeles VORTAC 

Los Angeles VORTAC direct to fenshaw lAF fMiramar) 

(Prom March missed approach) direct to Ladds lAF (Miramar) 

P India Route 5 0 (Norton APB) (Henshaw-Three Departure) 

Thermal VORTAC direct to Needles VORTAC 
Needles VORTAC via J-6 to Hector VORTAC 
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Hector VORTAC direct to Mentone HAP 

(from Norton niissed approacli) direct to March 

March VOR direct to Ladds I^J _^ _ 

CARRIER OPERATIONS MODULES 

Follow CATCC Vectors to Marshal Polat 
Navigate to Marshal Point 



APPROACH MODULES 

Shore Facilities 

Hi-TACAN Miramar 
Hi-TACAN Miramar 

Random Radar Vector to GCA Piclcup/ Miraniar 

Random Radar Vector to Hi-TACm A lAF , Mirainar 

Random Radar Vector to Hi-TACAW B lAF , Rirainar 

Hi'-TACAN to Kun^ay 5, Nortori APB 

Hi-TACAN to Runv/ay 16, Georg^e WE 

Hi-TACAN to Runv/ay 31/ March AFB 

Random Radar Vector to GCA Pictup, MCIS, Yuma 



(PAR) 



Ship 

Holding Pattern at Marshal Podrit 

Mode I (Autoinatic) Approach 

Mode I-A (Automatic to 0*5 miles) ApF^roach 

(DLC Final Approach) 
Mode 11 (Manual) Approach, CACLS Guidaace) 
Mode II Approach for APC Firial 4pproa.ch Technlqus 
Mode II Approach for DLC Final kppro^ch Technique 
Mode III Approach for Area Sur^eillaace Raaar (ASR) 

Final Approach 
Mode III Approach for Precisiori Approaca Radar 

Pinal Approach 
Mode III Approach for ASR fflnsL, MC TeChnrque 
Mode III Approach for ASR Final, DLC Technique 
Mode III Approach for PAR Final, MC Technique 
Mode III Approach for PAR Final, DLC Technique 

PINA.1 APPROACH MODULES (Vital ceilings yet to be accounted for.) 

Mode 1/ Ship (Autoinatic) 

Mode If Miramar (AUtoniatic) 

Mode I-A, Ship (Autoinatic to 0.5 mile) 

Mode 1-hr Miramar 

Mode II f Ship (Steering N&edles) 

Shipr APC (Automatic Power Control rachnaque) 
Ship DLC (Direct Lift Control TeGhnique) 
Miramr 
Miramar, APC 
Miramar f DLC 



Mode II ^ 
Mode II f 
Mode II, 
Mode II, 
Mode II, 
Mode II-T, 
Mode II^T, 
Mode II-T, 
Mode II-'T, 



Ship (Steering Naedles plai Voice Controller) 
Ship, APC 
Ship, DLC 
Miramar 
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Mode Il-Tr Miramar, APC 

Mode ll--Tr Miramar, DhQ 

Mode III, Ship CCA 

Mode III, Ship CCA, APC 

Mode 111, Ship CCA,. DLC 

Mode HI, Mirainar GCA (Normal Conf lgy;"r?.tion) 

Mode III, Miramar GCA (Auxiliary Flap I^ailurs) 

Mode HI, Miramar GCA (Aft Wliig Sv%ep iiandlrig) 

Mode III, Miramar GCA (No Plap/No Slat Laiidiftg) 

Mode III, Miramar GCA, APC 

Mode III, Miramar GCA, DLC 

Mode III, George AFB GCA 

Mode III, March AFB GCA 

Mode HI, Norton AFB GCA 

Mode III, MCAS, Yuma GCA 

LiAlNDING/RBCOVBRY MODULES 

Carrier R&covery 
Runway (Rollout) Miramaar NAS 
Runway (Rollout) Yiama MCAS 
Arrested Runway Ldg^, Mirama:^ 

MISSED APPROACH iMODULES 

Shore Pacilitiea 

Mirattiar Runway 24 R Missed ApptoaGh (Mode II Approach) 
Mirainar Runway 24 R Miaaaa Apptoaah (Mode HI Approach) 
Norton AFB Runway 5 Missed Approach 
Georgo AFB Runway 16 Missed A]^proach 
Marah APB Runway 31 Missed Approach 

Ship 

Bolter/Waveof f (Modes 1^^ ancj 12 Approaahea) 
Boiter/Waveof f (Mode HI CCA AppWach) 
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APPEUDrX B 

LISTING OF FAILURE (EMERGENCY) TASK MODULES 



Systein/SybBystem 



Air Data Co^iputer 



Pailures 



ADC failura 

Approach Indexer lights failure 
CADC caution indiaator light on 



Armament and Stores 
System 



Gun firing failure 

Missile status flag select 
failure 

Missile/store release failure 



Communicaticns/Navigaticn 
System 

Communications 



Navigation 



Auxiliary tJHF failure 
Headphone preanip failure 
ICS filter failure 
Main UHF failure 

ADF failure 

AHRS adv^isory indticafcor light on 

AWCLS AN/SPN-4 2 failure 

CSDC data freeze 

Data link failure 

ILS failure 

IMU unreliable 

Pilot bdhi failure (TACAN displa; 

Radar altimeter unreliable 

Radar failure 

TACAN malt test failure 

TACAN serial data failure 



Electrical Sourer Systein 
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Dual transf ormer/rectif ier failus 
Emergency generator failure 
HSD electrical power failure 
HUD electrical power failure 
left ac power generator failure 

T f ^ 
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System/Subsystcrn 



failures 



ELectrical Power 
Systeni (cont ) 



Lighting 



L GEN caiitioii indicator light on 

Right ac power generator failure 

R GEN cautiori indicator light on 

TRAK /RECT advisory indicator 
light on 

VDI electrical power failure 

CANOPY caution indicator light on 

Interior light failure 

LADDER caution indicator light on 



Environmental Control 
Syste^m 



Anti-Ice Systam 



BLEED DIJCT caution indicator 
light on 

Bleed diict failure 

Cockpit pressuri nation leak 

BCS failurt 

Main bleed air regulator failure 

OKY LOW ca\itlon indicator 
light on 

Oxygen low 

hOh heater circuit breakar 
failure 

INLET ICE caution indicator 
light ori 

Pitot static heater failure 

WSHLD HOT advigory indicator 
light on 



Fire Detection Systam 



Fire detection short circuit 



Flight Control Systems 

Primary Flight Control 
Systems 



Autopilot caution indicator 
light on 

HZ TAIL AUrH caution indicator 
light on 

MACH TRIM advisory indicator 
light on 
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Systefti/Subsystein 



Palliires 



Primary Flight Control 
SysteiTie (CQnt) 



Secoridary Flight 
Control SysternS 



Pitch stabilization channel A 
failure 

PITCH STAB 1 caution indicator 
light on 

PITCH STAB 2 caation indicator 
light on 

Pitch trim motor failure 

Roll stabilisation channel A 
failure 

ROLL STAB 1 caution indicator 
light on 

ROLL STAB 2 caution indicator 
light on 

RUDDER AUTH caution indicator 
light on 

Rudder auttiority stops failure 
Runway pitch trim 
Runway roll trim 

Yaw stabllizatiQn channel B failure 
YAW STAB OP caution indicator light on 
YAW STAB OTT caution indicator light on 

Emergency flap control failure 
(down) 

Emergency flap control failure 
(up) 

FLAP caution indicator light on 

Plaps/slats Tnalfunctlon 

Asymetrical Flaps 

GLOVE VANE caution indicator 
light on 

Left glove vane servoaGtuator 
failure 

Left outboard slat actuator 
f ailura 

Main flaps/slats S auxiliary 
flaps failure 

Right auKiliary flap actuator/ 
relay failure 
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Systcrn/Subsytitom 



Failures 



Secondary Flight Control 
Systams (Cont) 



Right glove vane servoactuator 
failure 

Eight outboard slat actuator 
failure 

Runaw^ay wing sweep channel 1 
control drive servo 

Speed brake switch failure 

SPOILERS caution indicator 
light on 

WING SWEEP advisory indicator 
light on 

Wing sweep channel 1 failure 
Wing sweep failure (2 chai:\nels) 



Fuel System 



Aft tank refuel/transfer valve 
fails closed 

BINGO caution indicator light on 

Forward fuel tank leak 

Fuel quantity indicator failure 

Fuel system imbalance 

Left wing ta :ik leak 

Left wing tank transfer pump 

failure 

L FUEL LOW caution indicator 
light on 

L FUEL PRESS caution indicator 
light on 

No external tank fuel flow 
R FUEL LOW caution indicator 
light on 

R FUEL PRESS caution indicator 
light on 

Right engine boost pump inoper- 
ative 



Hydraulic Power Systems 



EKLC 



Combined hydraulic power system 
failure 

Combined hydraulic power system 
partial failure 
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Sys tarn/Subsystem 



Failures 



Hydraulic Power Sy stems 
(Cont) 



Flight control backup module 
failure 

Flight hydraulic power system 
failure 

Fliynt hydraulic power system 
leak 

HYD PRESS caution indicator 
light on 

Mid outboard spoiler module 
failura 



Landing Gear Systeitis 



Arresting hook failure 

BRAKE warning indicator light on 

Landing gear down look solenoid 
failure 

Landing gear handle relays 
failure 

Landing gear safety relays 
failure 

LAUNCH BAR advisory indicator 
light on 

Left landing gear uns&fe 
Low brake accumulator 
Nose landing gear unsafe 
Nosewheel steering failure 
Right landing gear unsafe 
Side brace fails to engage 
Tire blowout 



Powerplant and Related 
Systems 

Afterburner Exhaust 
Nozzle Control Syetem 

Air Inlet Control 
Systein 



Left exhaust no^^le failure 
Right exhaust nozzle failura 

Left AICS malfunction 

L INLET caution indicator 
light on 

L ^MPS caution indicator 
light on 
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System/Subsyste 



m 



Failures 



Air Inlet Control 
System (Cont) 



Engine 



Oil System 



Right AICS malfunction 

R INLET caution indicator 
light on 

R RAMPS caution indicator 
ligh . on 

Left afterburner blowout 

Left engine compreesor stall 

Left engine fire 

Left engine flameout 

Left engine overtemperature 

Left engine seizure 

Left hung engine 

L OVSP/VALVE caution indicator 
light on 

Right afterburner blowout 

Right engine compresaor stall 

Right engine fire 

Right engine flameout 

Right engine overtemperature 

Right engine seizure 

Right hung engine 

R OVSP/VALVE caution indicator 
light on 

Left engine oil pressure 
fluctuation 

Left engine oil pressure lov^ 

L OIL HOT caution indicator 
light on 

OIL PRESS caution indicator 
light on 

Right engine oil pressure 
fluctuation 

Right engine oil pressure low 

R OIL HOT caution indicator 
light on 



112 



NAVTRAEQUIPCEN 76-C-0096-1 



SYStem/Subsystem 



Starting and 
Ignition System 



"nhrottle Control 
System 



Failures 



Left engine hot start 

Left engine ignition failure 

Right engine hot start 

Rigi.t angine ignition failure 

Auto throttle failure 
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APPBNDI5C C 

EXAMPLES OF EXPANDED FLIGHT PROFILE MODULES 
Seawolf-Seven Departure, Miramar 

Climbing tight turn to 3 00° magnetic to intercept NKX 
ThCm Radial 280 

intercept 280 radial at 2^000 ft. 

Ply outbound 28 0 radial at 2,0 00 ft. to Seawolf 
(NKX DME = 7 mi . ) 

Climb outbound on 280 radial to 14,000 ft. 

Fly outbourid on 28 0 radial to W-291 boundary (NKX DME = 31 mi 

San Pedro-Five Departure, Mirarnar 

Climbing right turn to 300° magnetic to intercept 
NKX TACAN radial 280 

Intercept 280 radial at 2,000 ft. 

Climb outbound on 280 radial to 14,000 ft. 

Fly outbound on 28 0 radial at 14,000 ft. to NKX DME = 20 mi. 

Intercept Mission Bay (MZB) VORTAC radial 300 

Climb outbound on 3 00 radial to assigned altitude 

Fly outbound on 300 radial to Tinny Intersection 
(M2B DME » 70 mi . ) 
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Hi-TACAN A, Miramar, ACLS (Mode 11) Approach 
Descend to 16,000 ft. 

Intercept Miramar (NKX) TACAN radial 060 at DME * 27 mi 

Alt = 16, 000 

Descend inbound on radial to 6,600 ft. at DME = 16 mi., 

250 KIAS 

Descend inbound on radial to 4,3 00 ft, at DME = 13 mi., 
2 50 KIAS 

Descend inbound on radial to 3,400 ft. at DME = 11 mi., 
250 KIAS 

Descfind/decelerate inbound on radi al to ADA = , Ldg 

configuration, at DME = 8 mi . , Altitude = 2,800 ft 



Hi-TACAN-A, Miramar, Missed Approach 

Arrest descent at DME 2.5 mi., NKX radial 060 inbound 

Level climb to 1,500 ft. ALT, inbound on O60 radial 
speed =2 50 KIAS maximum 

Configure aircraft for cruise 

Right turn to 360" magnetic, after a beam of NKX TACAN 
speed = 2 50 KIAS maKimum 

Climb on 36 0 heading to 5,000 ft. by DME = 13 mi., 
speed = 250 KIAS maximum 

Right turn to 13 mile DME ARC, ALT « 5,000, 
speed = 250 KIA.S maximum 

Fly 13 mi. DME ARC to intercept NKX TACAN radial 0 60, 
DME = 13 mi. 

Right turn to intercept 05 0 radiol inbound 

Descend inbound to 3,400 ft. at DME = 11 mi., 250 KIAS 

Descent/decelerate inbound on radial to AOA = Ldg. 
configuration, at DME = 8 mi, , altitude « 2,800 ft 
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